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Abstract 

1 haw de signed and implemented a system for the multilevel verification of 

sThem ^ SI CirCUitS - The System ’ called Silica Pithecus, accepts the 

behalf S I-*” 1 ™ and a Specification of the circuit’s intended digital 

behavior. Silica Pithecus determines if the circuit meets its specification. If the 

for th/f 1 -! “n Spe ? fication Silica Pithecus returns to the designer the reason 

the failure. Unlike earlier verifiers which modelled primitives (e.g., transistors) 

Tr^sfr 1<>na fn f eV1CeS ’ SUiCa Pithecus m °dels primitives more realistically. 
Transistors are modelled as bidirectional devices of varying resistances, and nodi 

andrcr^„t“ir P ““ 0 ”' “““ Wer “ chi “ U * toteractively, 

Major contributions of this research include a formal understanding of the rela- 
^onship between different behavioral descriptions signal, boolean, and arith- 
metic descriptions) of the same device, and a formalization of the relationship be¬ 
tween the structure, behavior, and context of a device. Given these formal struc- 
ures, my methods find sufficient conditions on the inputs of circuits which guar- 
a ntee the correct operation of the circuit in the desired descriptive domain. These 
methods are algorithmic and complete. They also handle complex phenomena such 
as races and charge sharing. Informal notions such as races and hazards are shown 
to be derivable from the correctness conditions used by my methods. 

Thesis Supervisor: Dr. Gerald Jay Sussman 

Title: Professor of Electrical Engineering and Computer Science 
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Chapter 1 
Introduction 


This research is both about verification of synchronous MOS digital circuits, and 
about a particular program, called Silica Pithecus , which is an implementation of 
some of the ideas in this thesis. Verification of digital circuits is a new, not yet 
well understood field. Its development is critical to building larger provably correct 
circuits The field is new enough that what verification is, what it means to verify 
a digital circuit, and how to verify a digital circuit are all largely unanswered (and 
sometimes unasked) questions. The goal of this research is to answer these ques¬ 
tions. Among the issues that must be addressed are: describing digital systems 
choosing appropriate electrical models, understanding how verification affects the 
esign process, relating simulation and verification, understanding the role of ab¬ 
straction, and relating structure, context, and function. 

This dissertation concerns multilevel verification and signal behavior generation. 
Circuit behavior can be described at different levels of abstraction ranging from the 
analog level to the functional level (Figure 1.1). Multilevel verification proves that 
wo different levels of behavioral description describe the same behavior. The higher 
(«.e., more abstract) level description of a design’s behavior is called its abstract 
behavior, the lower level description of a design’s behavior is called its concrete 
behavior. The proof has two parts: abstracting the concrete behavior to the same 
omain as the abstract behavior, and then proving the abstracted behavior and the 
abstract behavioral description are equivalent. 

The signal descriptive level and the digital descriptive level are the two descrip¬ 
tive levels we will primarily investigate. A signal is a time-varying voltage. The 
primitives operators of the signal level are transistors. A digital value is either 1, 
0, or float. The primitive digital operators are AND, OR, NOT, and join. The digital 
descriptive level is time free and functional. It has no time delays or switching 

elements. This allows a digital behavior to be specified as simple combinations of 
primitives. 1 


1We wiU usc the term “hardware digital level" to refer to a digital description which incorporates 
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_ Property 


Data Values 


Time Modelled? 


Types of Primitives 


Relational 


Table 1.1: The signal level versus the digital level. 


Digital and signal behavior differ in three ways (Table 1.1). First, digital values 
are incomparable to signal values. Second, circuit primitives are relational 
bidirectional) whereas digital devices are functional unidirectional). Third 

S st T'TT* m C - rCU T l tS ’ the rClatiVe ° rder in which events affects the 

instantaneously. 6 ^ ^ they C ° m P Ute their -suits 

si^nll'f ? C ° nd !° CUS .f this dissertation is the automatic generation of a circuit’s 
signal behavior from its structure (schematic). Signal behavior is the behavior of a 
circuit when viewed as a map from input signals to output signals. A signal is a time- 
varying voltage — intuitively, it what we observe on an oscilloscope when we probe 

oneofth T r w ng ^ Slgnal behavior of lar 8 e circuits from their structure is 
oTonw X T'T thiS research - The is focusing the generation method 
behavior hOS6 ? ° f a clrcuit ’ s ful1 behavior that account for the circuit’s digital 

Verifying circuits is difficult for many reasons (Table 1.2). First, circuits are 
huge. Chips of up to half a million transistors are becoming common. Brute force or 
linear techniques simply fail. Seco nd, the signal behavior of a circuit must be derived 

time and switching devices. 
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• Circuits are huge, up to half a million transistors. 

• We must derive a circuit’s behavior from its structure. 

• We must employ accurate circuit models. 

• A verifier must be fast. 

• Ad hoc systems are not enough to prove correctness. 


Table 1.2: Five reasons why verification is a hard problem. 


• Exploiting the hierarchy and structure of schematics. 

• Using intentional analysis. 

• Employing circuit models accurate enough to model the most common bugs. 

• Having a formal statement of circuit correctness. 

Table 1.3: Four techniques for attacking the complexity of verification. 


from the circuit s structure (schematic). Unfortunately, determining a circuit’s full 
behavior is very hard and expensive. It is difficult to do either analytically or 
empirically. Third, accurate circuit models must be employed. Circuit models which 
are too simple will fail to catch bugs. On the other hand, circuit models which are 
too complex may make verification impossible. Fourth, an verifier must be efficient 
and fast to be usable. A designer needs quick response from his design system. 

Fifth, we want to prove our circuits are correct; merely finding and reporting bugs 
does not a verifier make. 6 6 

I have designed and implemented a system, called Silica Pithecus, for the multi- 
evel verification of circuits. It accepts the schematic of a circuit and a specification 
of the circuit s intended digital behavior and determines whether the circuit meets 

% S lTfT° n : SU ! Ca Pithecus 11863 four techniques to solve the above problems 
( a e 1.3): it exploits the hierarchy of a design, it uses intentional analysis, it 

employs circuit models accurate enough to catch the most common bugs, and it has 
a formal statement of circuit correctness. These are discussed below, in turn. 

The hierarchy that is used to create a complex circuit is exploited during anal¬ 
ysis. Verification operates from the leaf nodes of a design to the root of the design. 
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A1 subcircuits of a circuit are verified before the circuit itself is verified. Two ben- 
efits accrue from this strategy. First, a circuit is verified only once - the first time 

TlT* “ “c “7" always used the same purpose, it need never be 
"77 SeC °" d V Verl , flCati ° n can be Performed incrementally as a design is 

created. The amount of work in verifying the composition of two previously verified 
subcircuits is proportional to the amount of new information created by the compo¬ 
sition. The amount of work is largely unrelated to the complexity of the subcircuits 
themselves. In terms of a usable, interactive system, finding errors quickly and 
incrementally is extremely important. Detecting bugs as they occur, rather than 
waiting until a design is complete, causes reevaluation of designs at an early stage. 
It is not inconceivable that a design flaw in a small segment of a design invalidates 

wasteful ° f ^ eSlgn * DetCCting the flaw onl y after the des ^ w completed is 

This approach keeps the design process interactive and incremental. Silica Pithe- 
cus is interactive because it can verify on demand any portion of the circuit, and 

‘ mcre ™ ntal because * analyze and verify parts of the circuit as they are 
entered A designer is able to analyze and verify designs as they are created, rather 
than wait until the entire design (chip) is finished. 

Intentional analysis is proving only the important properties of a circuit hold. 

hs dSt!7™ 7 rcuit n °* be known t0 verify ‘he circuit meets 

digital specification. For example, it usually doesn’t matter whether a signal’s 

™£** “ f°7 e ‘ ,m V 3 ,“- 5 ,7 4 6 volts ’ AU that « important is that it is above 
atTJS i° T Slm ' Urly ’ a “ that matter about a signal could be its value 

at steady state In this case it is unnecessary to calculate its intermediate values. 

Zj. J* ?“ Va "‘ , part3 ° f a circ,lit ’ 3 behavior and ignoring the irrelevant 

p S, predicting a circuit s behavior becomes a tenable proposition. 

f\ S f 1 , llCa v Pl 1 t , he k CUS ’ S com P° nent models are accurate enough to model (the sources 

*2 hold bUgS ’ ratl ° bugS ’ Charge sharin 8 bugs, hazards, and races. These 
are the most common circuit bugs and the most complete set of bugs modelled by 

any one system (cf .Table 1.6). Silica Pithecus’s models do not include capacitive 
caughT 8 ° r UnC ° cked feedback ’ 80 bu 8 s arisi ng from those phenomenon are not 

, ^ fo - aI statement of circuit correctness prevents Silica Pithecus from being 
hoc. The basis of the statement lies with the abstraction function used to map 
signals into digital values. The correctness statement guides much of the impl " 
mentation, dictates the relationship between the actual and intended behaviors of a 

ofTcircu^ f ° rma 1Z6S the relationshi P between the structure, function, and context 

My theory of verification is designed for verifying synchronous MOS VLSI digital 

T n0t concerned with asynchronous circuits or process 

echnologies other than MOS. Neither are we concerned with non-digital designs, 
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but it ,s harder to characterize what these are. For example, why is a bootstrap 
driver or a sense amplifier not a digital circuit? This dissertation defines as non- 
digital any circuit which relies on a race condition that can not be resolved using 
ga e-delays. A bootstrap driver relies on a race between the driven node and the 

oad node, it is non-digital. Similarly, a sense amplifier relies on a race that is not 
the result of gate delays. 

Randy Bryant [Bryant86] imported the terms false negative and false positive 
into the vernacular of hardware verification. A false positive occurs when a verifier 
declares an incorrect circuit to be correct. Silica Pithecus is guaranteed never to 
give false positive. A false negative occurs when a verifier declares a correct circuit 
to be incorrect. Due to Silica Pithecus’s conservative nature, it will give many 
ot these., False negatives mainly arise when a circuit is more complex than Silica 
Pithecus s proof procedures and constraint processors can handle. Very often the 

form its false negative is “I can’t prove this circuit is correct” rather than “This 
circuit is incorrect.” 


This chapter has seven sections. The first section gives an overview of Silica 
Pithecus and gives an example scenario. The second section discusses hierarchical 
verification. The third section gives some results of running Silica Pithecus on 
different circuits. The types of circuits which Silica Pithecus can verify are presented 
in the fourth section. Section five compares this research to other methods for 
verifying circuits. The sixth section highlights the contributions of this research 
The last section gives an annotated chapter listing of this dissertation. 


1.1 Scenario 


A schematic of Silica Pithecus appears in Figure 1.2. Silica Pithecus has three 
mputs and two outputs. Two of the inputs, the schematic of the circuit to be 
verified and the circuit’s intended digital behavior, were discussed above. The third 
input, logical constraints, are boolean expressions on the (digital abstractions of the) 
inputs of the circuit being verified. These boolean expressions are guaranteed to 
always be true. For example, logical constraints might dictate that the two clocks 
0i and 0 2 are mutually exclusive. Other examples are dictating that a certain input 
is always asserted, or that either of two inputs will always be asserted. 4 


2 This is an idealized representation of Silica Pithecus’s input/output behavior. Silica Pithecus runs 

L ‘ ra f V r ^ , em " CirCUitS and pr0grams coexist “ the same database. Silica Pithecus 
has a couple of implicit inputs which are not represented in this diagram. 

^L^ithecusT ^" 48 Tk r Crified t0 u- When a circuit “ used « P art o' a l"ger circuit. 
Mlica Pithecus does not believe everything the designer says. 

! ? iCal 1 C ° n8traint8 ’ stead * ‘ogical constraint,, and temporal logical 
constraints. Steady state logical constraints make assertions about the boolean interpretation of 
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Constraints Either CORRECT or INCORRECT, Here’s why 


Figure 1.2: Silica Pithecus as it appears to the user. 


One of the outputs of Silica Pithecus is a declaration of whether the circuit 
meets its digital specification, i.«„ is correct. If the circuit is not correct, then the 
reason it is not correct is given to the designer. Example reasons include reporting 
ratio bugs, threshold bugs, or glitches. 

The other output is a set of constraints on the input signals. When satisfied, they 
guarantee that the circuit will exhibit its specified behavior. A given structure can 
exhibit many different behaviors; the constraints “project” out the desired subset of 
a structure s possible total behavior. 5 Structure alone does not determine function, 
structure and context together determine function. Examples of constraints include 

dictating that some input signal must not glitch or that some input signal must not 
sutler a threshold drop. 

Constraints are a very powerful idea. They allow very large circuits to be ver- 

vk-^ 11611 1 S ^ b J cir J cmt ’ s constraints are met, it means that the subcircuit will 
exhibit its specified digital behavior. Therefore, to generate the digital behavior 
of a circuit all of whose subcircuits have been verified, one need only prove all the 
su circuit s constraints are met, and then compose the subcircuit’s digital behav- 

assertk>ns 3 abcmf th reaches 8tead y stat «* Temporal logical constraints make 
assertions about the boolean interpretations of the values of signals for all time. 

*“i ly u !■“ * »""• for this observation, they e.11 it the J\r..>.el,„„. 

cated on the o^ilS:" 1 - » *'»*>" P™* 
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Figure 1.3: A Inverting Latch. 


iora. This method of generating digital behavior is very fast because the signal level 
behavior of the circuit need never be generated. We will return to this topic when 
we discuss hierarchical verification. 


Example 

Consider an Inverting Latch (Figure 1.3). This device stores one bit on its S node. 
The output of the Inverting Latch is the negation of the value on its S node 
The digital specification of the Latched Inverter is 

(df ((INVERTING-LATCH s) latch in) 

(stream-cons 

; this is the output 

(if latch (not in) (not s)) 

; this is the next state 
(INVERTING-LATCH (if latch in s)))). 

• T * hlS i P /°* ran * ! ays that an Averting Latch has one bit of state, s, and two 
inputs latch and m. The inverter “returns” two values, the output and the next 
state of the device. The output and next state both depend on the state of latch. 6 

When Silica Pithecus is handed the schematic and digital specification of the 
Invertmg Latch, it declares that the circuit is correct and generates four constraints 
liable 1.4). The first constraint requires that whenever Latch* is true, signal flow 
must be from In to S. If signal flow is not from In to S, say, because In is a 
precharged bus and S has more capacitance than In, then the circuit will not have 
its intended digital behavior. Th e second constraint requires that if Latch* falls 

6 This is not a complete description of the program. A complete description appears in Chapter 7. 
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1. Latch* =>• overpowers([In] /ri , [S] 5 ) 

2. falls (Latch*) =» falls-first(Latch„In.) 

3. control(Latch.) 

4. no-drop(Latch.) 

T’aWe i 4; Gonstraints on the latched inverter cell. Latch, refers to the signal at 
node Latch. Latch* refers refers to the boolean interpretation of the signal at node 
Latch. The other notations are described in later chapters. 


during a computation 7 then it can only do so before In. changes state. That is, 

wwT 1 !f able T ° n com P utations w hen Latch, falls, or, if In. is unstable 
when Latch, falls, then In. must change after Latch, falls. The third constraint 
requires that once Latch, is asserted, it must remain asserted. The fourth constraint 
requires that Latch, not suffer a threshold drop. Latch, is prevented from suffering 
a threshold drop so that S, does not suffer two of them. If any of these constraints 
are violated, the circuit will not exhibit its intended digital behavior. 

When a verified subcircuit is used as part of a larger circuit the subcircuit’s 
constraints are checked. I anticipate that most errors in a design will be caught 
by the detection of violated constraints. Designers constantly work within semi¬ 
conscious digital abstractions of the analog properties of their designs. It is when 
ey unknowingly break these semi-conscious digital abstractions that errors arise. 
The constraints that Silica Pithecus generates embody these semi-conscious digital 
abstractions therefore breaking the now concrete abstractions cause the constraints 
to be violated, and an error to be returned to the designer. 


1.2 Hierarchical Verification 

sipnai SP 5" dS T' ,° f “ S e " ergy geMratin 8 “<> abstracting a circuit’s 

signal behavior. Hierarchical verification is a method of avoiding much of this 

work. Consider a circuit composed of previously verified subcircuits (Figure 1.4). 

hen the digital behavior of the whole can be derived from the digital behavior of 
the parts the signal behavior of the whole device need not be generated. 

This is precisely what hierarchical verification does. Hierarchical verification first 
processes the constraints of each subcircuit. If no constraint is violated, then the 

7 ftl?r P Thu'°A n SU T :„ hen fr cl ° ck changes state - A computation ends when the circuit reaches 
state. This idea is further elaborated in Chapter 3. 
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D 



Figure 1.4: Hierarchical Verification. D is the whole design. Each part d, is assumed 
to be verified. The c,’s represent the constraints on each d. ’s inputs. Assuming that 
none of the constraints are violated, the digital behavior of the whole design can be 
derived by composing the parts’ digital behaviors. A constraint that can be neither 
proven nor disproven is propagated as a constraint of the top level circuit D: C 
stands for the propagated constraints. 


digital behavior of the whole is derived from the digital behavior of the subcircuits. 

There are three possible outcomes of processing constraints: a constraint can 
be accepted, rejected, or propagated. A constraint is accepted when it is shown to 
old. A constraint is rejected when is is proven not to hold. Rejected constraints 
are returned to the designer as errors. When there is not enough information to 
show that a constraint either holds or doesn’t hold, the constraint is propagated 
up the structural hierarchy to be reprocessed when the circuit itself is used as a 
subcircuit. For example, because the input constraints Cl of component Dl in 
Figure 14 neither hold nor fail to hold, they are propagated as constraints on the 
inputs of D. Processing constraints is fast and efficient. There are five types of 
constraints. They are enumerated and discussed in Chapter 11. 

Asa concrete example of hierarchical verification, consider a Shift Cell built out 
of two Latched Inverter Cells (Figure 1.5). The specification of this device employs 
the specification of the Inverting Latch. 

(df (SHIFT-CELL si s2) 

(let ((Left (INVERTING-LATCH si)) 

(Right (INVERTING-LATCH s2))) 
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Figure 1.5: Composing Two Latched Inverter Cells to Make a Shift Cell 


(lambda (in 11 12) 

(Right (Left in 11) 12)))) 


This digital specification says that a Shift-Cell takes two inputs and that its behavior 
is equivalent to two inverting latches, one feeding the other. 

There is one logical constraint for the shift cell: tmutex(Ll„ L2,). It declares 
that LI, and L2, are mutually exclusive. 

When given the above information, Silica Pithecus declares the Shift Cell to be 
correct and generates the following six constraints: 

• Li* => overpowers([In ] In , [(S Left)] (5ie/t) ) 

• control(Ll,) 

• control(L2,) 

• no-drop(Ll,) 

• no-drop(L2,) 


• falls(Llj) => falls-first(Ll„ In,) 


These constraints result from propagating the unresolved constraints of the two 
Inverting Latches to the Shift Cell. Of the eight constraints (four for each Inverting 
Latch), only two were satisfied: 


' L2 ‘ =• °verp 0 ».rs([C] c ,[(S and 

• falls(L2ft) —* falls-first(L2,, C,). 
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Carry through 

71 xtors 

12.2 seconds 


Carry through 

71 xtors 

0 seconds 


Carry through 

71 xtors 

0 seconds 


Restored output 

71 xtors 

3.8 seconds 


284 xtors 9.4 second* 





25.4 seconds total 

Figure 1.6: Verifying a 4 bit Manchester Adder. 


Note that as part of propagation, the names of nodes are changed from being local to 
the Inverting Latches to being local to the Shift Cell. For example, no-drop(Latch,) 
(for the left cell) becomes no-drop(Ll.). When a node has no corresponding name 
tor it at the higher structural level a name based on the “pathname” of the node is 
generated for it. For example, the S node of Right is changed to (S Right) and the 
S node of Left is changed to (S Left). 


1.3 Results 


T he time required to verify circuits is extremely encouraging. 8 Silica Pithecus has 
verified circuits of 9,000 transistors in 80 seconds. One particularly enlightening ex¬ 
periment is the one originally performed by Randy Bryant for MOSSYM [Bryant85l 
and repeated using Silica Pithecus. 

In this experiment the ALU from [Mead/Conway] is programmed as an adder, 
which special^es it to be a precharged manchester adder [ref manchester adder]. 
I his adder is a subtle device which uses many MOS features, and it is therefore an 
extremely good test case for an MOS verifier. 


Silica Pithecus verifies a 16 bit adder (over 1100 transistors) built from this 
cell m 51 seconds. The breakdown of times for this is very instructive. Consider 
the verification of a four bit adder, which takes 25.4 seconds (Figure 1.6). The 
first adder cell takes 12.2 seconds to verify. To verify a four bit adder takes an 
additional 13.2 seconds. Of this additional time, 3.8 seconds is spent verifying a 
s lghtly different version of the adder cell where the carry-out line is restored, and 
9.4 seconds processing the constraints of the four cells. By not reverifying the same 
part ’ and not generating signal behavior, hierarchical verification avoids extra work. 


*The timings here are preliminary. Silica Pithecus is not completely implemented. The timings 

are all within a factor of two, probably a lot less. By no means is Silica Pithecus tuned. A tuned 
version might run much faster. 
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1.4 Other Work 

Other work in ensuring circuits operate correctly is in four broad areas, bottom-up 
and top-down methodologies, simulation, electrical rules checking, and verification. 


1.4.1 Verification Versus Methodology 

Bottom-up and top-down methodologies are used to build circuits free of certain 
bugs. 

Bottom-up methodologies have two components: restrictions on the types of 
circuits that can be built, and restrictions how circuits can be composed to make 
larger circuits. These restrictions eliminate both certain classes of bugs and circuit 
classes of circuits. For example, threshold bugs are one type of bug that can be 
prevented by requiring that all signals coming from pass logic be restored. The 
cost of preventing this particular bug, however, is very high. Requiring all signals 

silicon 68 * 01641 6XC UdeS 1111117 types of circuits from being designed and costs extra 

Top-down methodologies start with a high-level, and therefore presumably cor¬ 
rect, specification of a circuit. The specification is incrementally refined into a 
concrete circuit. A fixed set of transformations are used during the refinement 
s age. Each transformation is guaranteed to preserve the correctness of the original 
specification and not to introduce any circuit bugs. 

Both top-down and bottom-up methodologies throw out the baby with the bath 

Wa !! r: J , make mefficient of chip area and create slow designs. 9 Furthermore 
methodologies can’t eliminate all classes of bugs — if they did, a designer would be 

° v er y restricted. For these reasons, we reject forcing designers to use a particular 
methodology. 


1.4.2 Simulation 


Today s designers debug their designs using simulation. Regardless of the level of 
simulation, simulation has many problems (Table 1.5), the foremost of which is 
simulation cannot guarantee the absence of bugs. As designs become more and 
more complex, simulation becomes less and less reliable. Exhaustive simulation 
must be performed to prove circuits are correct. But exhaustive simulation for 
large circuits is either exponentially expensive (when a boolean or digital domain is 
used) or impossible (when an infinite domain such as signals is used). Verification, 
which proves that a circuit works as intended for all inputs and state transitions, 
is completely reliable. Another problem is that simulation decontextualizes bugs. 


9 There is no theoretical reason for the resulting inefficiencies. Nonetheless, 
are wasteful of resources. Future research may alleviate this problem. 


current technologies 
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Simulation 

Verification 

Is not complete 
Decontextualizes bugs 
Is non-compositional 
Weak circuit models 

Is complete 
Pinpoints bugs 
Operates hierarchically 
Accurate circuit models 


Table 1.5: The Failure of Simulation. Simulation has many problems which verifi¬ 
cation does not have. 


The output of a simulator is l’s and 0’s. When a 0 appears where a 1 was expected 
(or vice versa, or when an unexpected X appears), there is no clue about the 
source of the bug (».«., whether it comes from a logic bug, ratio bug, etc.). The 
designer must laboriously track down the source of the bug. This is true even 
when exhaustive simulation is performed. A verifier automatically pinpoints the 
parts of an implementation which do not match their specification; this precisely 
locates bugs. A third problem is that simulation is non-compositional. Even when 
al of a circuit’s subcircuits are verified via simulation, the circuit itself must be 
ully simulated. Non-composibility is the key reason simulation cannot be used to 
verify large circuits. Finally, because simulators must constantly reevaluate the 
same subnetworks over and over again, simulators must used impoverished circuit 
models. Accurate circuit models would be too expensive to use for large scale 
simulation. Because verification only looks at each possible network once, it can 
use a more elaborate circuit model. 


Symbolic Simulation 

Recently symbolic simulation has been proposed for the verification of digital MOS 
circuits. Symbolic simulation uses variables and constants during simulation [Bry- 
ant85]. When a circuit is symbolically simulated the result is an algebraic expres¬ 
sion. This algebraic expression is then verified to be the expression expected. Due 
to symbolic simulation’s algebraic structure, it is capable of simultaneously simu¬ 
lating a circuit for many different inputs. This feature makes exhaustive simulation 
easier for some circuits. 

The major problems with symbolic simulation are lack of coverage, inability to 
catch races and hazards, decontextualization of bugs, and lack of composability. 
These problems arise because symbolic simulation is tied to a simulation paradigm 
thereby inheriting the problems of simulation. 

Lack of coverage means that symbolic simulation does not prove that for all 
inputs and states a circuit gives the correct output and goes to the correct next 
state. The problem is that a purely symbolic simulation would simulate transitions 
and states that never occur and would yield many spurious errors. To avoid this 
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problem, a designer must select simulation sequences that yield only states and 
transitions that can occur during real usage of the design. For example, if a device 
has two mutually exclusive inputs, then it is symbolically simulated twice: once with 
one input high and the other low, and once with the inputs reversed. Therefore, to 
get complete coverage, a designer must carefully craft a set of test sequences which 
fully exercises the chip. 

MOSSYM does not use MOSSIM’s unit delay model. Instead, it uses Naher’s 
[Naher] rank-order delay model. Therefore MOSSYM cannot verify the timing 
behavior of circuits. Bryant advocates the use of ternary simulation [Bryant83] 
as an extra pass to get around this problem. However, ternary simulation only 
finds races, therefore this methodology cannot verify circuits which rely on races. 

Like normal simulators, symbolic simulation decontextualizes bugs. The only 
difference is that symbolic simulation outputs boolean expression where normal 
simulation outputs ones and zeros. When discrepancies arise between the expected 
and actual results of simulation, the designer designer must still determine the cause 
of the discrepancy. 

Symbolic simulation is not composible. It is a monolithic tool and cannot take 
advantage of hierarchy. If two subcircuits are verified via symbolic simulation, this 
gives no handle what happens when the two subcircuits are composed. Symbolic 
simulation is at least quadratic in its running time, therefore it cannot be used for 
large circuits. 


Understanding why symbolic simulation is non-composable is very instructive. 
The basic problem is that the simulator assumes inputs are both driven and stable. 
For many circuits this assumption is invalid. The real inputs to a circuit may 
be precharged values rather than driven values, and they usually are not stable. 
Symbolically simulating a circuit does not indicate what the circuit does when 
connected to real signals. Therefore when a previously “verified” circuit is used as 
part of a larger circuit, the larger circuit must be simulated in its entirety. 


1.4.3 Electrical Rules Checkers 

Electrical rules checkers ensure that circuits are not malformed according to some 
structural criteria. Electrical rules checkers suffer from two major problems. First, 
they are completely ad hoc because they check that very specific configurations of 
circuits don’t arise. Second, they often give many annoying spurious errors. 

The first commonly used electrical rules checker was Baker’s [Baker]. This 
checker made sure that each node could be potentially pulled up and pulled down, 
that depletion mode transistors were used in known ways, that two or more thresh¬ 
old drops didn t occur, that Vdd and Gnd weren’t shorted together, and that proper 
ratios existed in gates. Its major problem was finding a tremendous number of spuri¬ 
ous errors because it had absolutely no understanding of a circuit’s logical structure 
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(«.?., which signals are mutually exclusive). It also had the problem of being non- 
hierarchical, it would find the same bugs over and over again. The output was so 

iy . tEat P™*™™ were written to filter out some of the spurious errors and 
to collect the repeated errors together. 

TV [Jouppi] was a timing analyzer that used some knowledge of a circuit’s 
operation to avoid the problems of spurious errors. It applied a set of ad hoc rules 
over a circuit to determine the direction information flowed through transistors. An 
electrical rules checker built on top of TV which had no spurious errors when run 
on sample circuits. One must use such a tool with caution, however. It suffers from 
two rela ed problems. The first is that TV’s methods for determining information 

^ e * PUr f- heunstlc and can fai1 without the designer knowing. Second, TV assumes 
that ratios are correct to determine information flow, it then uses information flow 
to check ratios. This approach can fail in expected, and undetected, ways. 

Karplus [Karplus] also has an ad hoc approach to electrical rules checking He 
treats circuits as graphs and then uses graph algorithms to prove certain paths (sub- 

S chik,°are Ur C ‘ rCUit h"”* Ch<iCked ' Examples of the * ra P h formation 

1. Avoid shorting power. 

2. Avoid changing the inputs. 

3. Avoid parallel pullups. 

4. Avoid gates in the middle of pulldown chains. 

5. Avoid charge-sharing. 

6. Avoid odd inverter cycles. 

Some of these rules are not well-motivated and potentially unneeded. For exam- 
ple, R ule 2, avoiding changing the inputs, is not needed when the input is connected 
to the output of a gate. The reason for avoiding parallel pullups is to make ratio 

o?n, 8 P ? ne t0 err ° r : The reaSOn for Rule 4 ’ avoidin 8 gates in the middle 
w Plld r C f ham j’ l * S °- ^ ad h ° C programs which tr y to determine signal flow 
get confused. Having ad hoc rules so that ad hoc programs will work better 
seems like poor methodology. Also, enumerating the ways a circuit can be mal¬ 
formed is not a good strategy. It is not clear whether all bad circuit formations can 


1.4.4 


Other Types of Verification and Other Verifiers 


ery little work similar to the work discussed in this dissertation has been done. 
People have worked on multilevel verification, and have worked on generating be¬ 
havior from structure, but always with a different focus than that presented here 
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The technologies and models used by previous researchers differ from mine, 
peci ca y, earlier work on deriving behavior from structure were either for TTL 
[Wagner], or used inadequate circuit models for MOS [Gordon, Barrow82]. The 
ypes of circuits built from TTL and from MOS are completely different, and the 
™t 3 ° f f Gordon82 ] a nd [Barrow] can’t catch charge-sharing bugs, ratio bugs, 
threshold bugs races, or hazards. Also, Wagner’s verifier was not automated and 
could only handle small circuits. Barrow’s verifier is discussed in detail below. 

ordon has since improved his model to make transistors be bidirectional and to 
nclude time [Gordon84b]. He uses higher order logics for describing and verifying 
circuits [Gordon84]. Using logic is an improvement over more functional approaches 
Logic easily captures the bidirectionality of transistors and logic is well known 

fb^tTwiH ’ 18 n ° b#tt f than earHer formalisms for describing, or reasoning 

about, the electrical aspects of circuits. 

Research on multilevel verification has also been done [Eveking] [Gordon84c| 
rev,ous work made explicit the notion of an abstraction function for mapping 
between levels. Some even had partial abstraction functions. However, none have 

rf f y thei role of constraints. One researcher [Eveking] noticed that 

constraints (he called them assertions) were needed to ensure inputs were valid 
(i.e. mapped into the higher level descriptive domain). He, however, did not make 
the observation that constraints were also needed to ensure outputs were valid. 

™“ ° ne ° f the contributions <> f ‘his dissertation and is the basis for 
automatically generating constraints. 

o„,i?„ the f at ' empts at . verifyin « M0S “K“i‘s will now be discusses, followed by an 
utline of other work in verifying diverse properties of digital systems. 


Verify 

Verifv S fR SiIiCa Si ° nIy ° ther .implemented verifier for MOS circuits is 

(Table 1 6)^° First SlUca Pithecus in two ver y important ways 

(lable 1.6). First, it has no explicit notion of abstraction or multiple levels of 

innof 1 !; i u a mo ™ veri fi er - Sec °nd, its circuit model is extremely weak. It 
cannot mode! charge-sharing bugs, ratio bugs, threshold bugs, races, or hazards. 

, w er ' fy s focuses on verifying digital designs. It models circuit components and 

resuTt that'‘sHicap 0 th^ 8 “ *** deViCeS ‘ < That is ’ Verif y assumes the 

result that Silica Pithecus is trying to prove, namely, that circuits can be described 

as time-free digital devices.) Given two different digital descriptions of the same 

design it can determine whether the two descriptions are the same. One of the 

descriptions is derived directly from the structure of the design, the other is the 

the C sam l 0n ‘ ^ behavior and its specification are described at 

the same level (».«., the digital level) an abstraction function is unneeded. 

(Silica Pithecus could use the capabilities of Verify. When Silica Pithecus verifies 
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Transistor 

Model 

Wire 

Model 

Bugs 

Modelled 




IKHiii 

1 Bit 

Logic 

ijordon 


Tristate 

Relational 

1 Bit 

Logic 

Timing 



Many Valued 
Signals 

Bidirectional 

Switch 

Capacitors 

Charge Sharing 
Timing 

Logic 

lerman 

RSIM 

Interval 

Signals 

Varying 

Resistors 

Capacitors 

Charge Sharing, 
Ratio bugs, 
Timing 

Logic 

Weise 

Silica 

Pithecus 

Signals 

Varying 
Resistors + 
Threshold 
Device 

Capacitors 

Charge Sharing, 
Ratio bugs, 
Timing, 
Threshold 

Logic 


Table 1.6: Verifiers and Simulators for MOS Circuits. This table shows the different 
characteristics of MOS verifiers and simulators. The top row highlights Verify. This 
verifier s strength is in verifying digital systems rather than verifying circuits. The 
second row highlights two popular simulators. These simulators have reasonable 
circuit models but don’t perform verification. The last row shows Silica Pithecus 
which has the best of both worlds. It can formally prove a circuit is correct, and 
its models are better than the simulators’ models. 


large circuits, their structural and functional specifications must match. This makes 
companng the abstracted and specified behaviors simple: Silica Pithecus shows 
that the subcircuits correspond to subfunction in the digital specification and that 
the wires m the circuit correspond to dataflow in the digital specification. The 
comparison of arbitrary digital expressions occurs only for leaf cells. Silica Pithecus 

and Verify ar e complementary programs, the former verifies circuits and the latter 
verities digital designs.) 

Functional Verifiers 

Functional verifiers are multilevel verifiers where the concrete domain is the digital 
level and the abstract domain is at some higher level such as the arithmetic level. 
Functional verifiers are complex because the abstract domain are very rich. Proving 
that two expressions denote the same value can require difficult theorem proving. 
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An . ^teresting func tional verifier was created by [Hunt]. He began with the 
Boyer/Moore theorem prover (Boyer). Wherever the theorem prover was inade- 

booUan 7T- ^ K ! b f M ° 0re ' The ? rimitives of Hunt’s circuits were idealised 
. .. r !!. y . lstat ®) gates. He designed a microprocessor and verified that it 

moof. w SPeC ‘1? BeCa , USe he emploJ,ed the Boyer/Moore theorem prover his 

d«° L u' 1186 lnduction - Therefore he could prove that parameterized 
d«criptioi>s of his circuits were correct, something no other verification system has 

done. For example, he was able to prove that his specification for an n-bit adder 

Si ”- ° th " verifiers (' S'- siIi “ Preens and 

inslS i^ ^ b f n Scnp ‘ 10n3 ’ but the descriptions must be concretely 
instantiated before verification can be performed. 


Protocol Verifiers 

TonTo? 1 V6rifierS ! h ° W t ^ t S ° me commun ication and arbitration scheme properly 
controls some system. For example, protocol verifiers prove that a system will 

always service or acknowledge a given request. Protocol verifiers are also used to 

2^f^ IOnOUS 7 Ste T‘ Pr ° tOC01 VCrifierS that Primitives respond to 

~ u m r TV S ° me finitC dday - The trick is to Prove that regardless 
of the delays which can t be accurately predicted, the system will still work. 

sv s^r? 1 ° glCS ^ ° ften USCd t0 Sp6Cify the desired Properties of asynchronous 
systems and communication protocols [Mishra/Clarkej [Moszkowski] [FujitaL They 
formalize notions such as “before,” “after,” and “following.” 7 

is 5 °, me confusi ° n in lhe community between verifying asynchronous sys- 

dr“it i^r^r'” 8 “ y " chronous The problem is that an asynchronous 

' ‘ I " lnsta "ce of aa asynchronous system. Therefore researchers sometimes 

IT are Ver ! fymg circuits " hei1 their methods have little to do with circuits 
• .• n*” clrcults are ^d to implement asynchronous systems). Their claim 

is partially true, however, the claim is beside the point. One could implement an 
asynchronous system using people, instead of circuits, and their methods would still 


Verification of Sequential Systems 

This category of verifiers proves that a system exhibits the correct behavior over 
nnml ^ incIude verifying that a bit serial adder really adds two 

havior ^ ^ Venfymg that microcode correctly implements its intended macrobe- 

VeriTHn^MOSS VM h ^ ^ “ ° d k ° C fashi ° n ° n this to P ic - Both 

enfy and MOSSYM have been used to verify a the correct behavior of a design 

microTod^of 7 S * n nfy ^ 6Xtended to verif y> with human intervention, the 
microcode of a small computer. MOSSYM has verified bit serial adders 
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Protocols Functional Level Sequential Systems 



Figure 1.7: Silica Pithecus’s place in the verifier community. 


verification 7 ^ ^ d ° ne ° n this is in the field of microcode 

Silica Pithecus’s place in the verifier community is shown in Figure 1.7. 


1.5 Contributions of this Research 

The mam contribution of this research is a formal abstraction mechanism for veri- 
fymg the signals of a circuit correctly implement the digital abstractions envisioned 
by the designer. This includes, for example, proving signals can be viewed as ones 
and zeros, that nodes are capable of storing bits, and that control signals don’t 
glitch A major difficulty is deciding which signals are intended by the designer to 
be state bits, control signals, or data signals. These concepts are related to the role 
of a signal and are unrelated to electrical considerations. 

The second contribution is an efficient method for the automatic generation 
of a circuit s signal behavior from its structure (schematic). This is one of the 
contributions of this dissertation. The key is focusing the generation method on 
only those parts of a circuit’s full behavior that account for the circuit’s digital 
behavior. No previous system with reasonable circuit models has predicted the 
behavior of large MOS circuits solely from their structure. 

Other contributions and ideas are listed below. 
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A formal model of multilevel verification. 

I precisely define what it means to prove a circuit is correct. Other researchers 
in multilevel verification have had a similar statement of correctness, but they all 
missed the role of context in their definitions of correctness. 


A method for formally deriving constraints. 

Besides specializing behavior, the purpose of constraints is ensure that the behav¬ 
ior of a given design is abstractable to the next higher level of description. This 

observation yields a method for automatically generating many of the constraints 
on a design. 


A formal statement of the relationship between structure, function, and 
context. 

Hierarchical verification depends on the explicit dependence between structure, 
tunction, and context. 


A method for symbolically predicting the behavior of a circuit solely 
from its initial state and inputs for any valid state and inputs. 

As mentioned several times in this chapter, Silica Pithecus must both derive a 
circuits signal behavior from the circuit’s schematic and also abstract the signal 
behavior to the digital domain. A major contribution of this thesis a method for 
efficiently deriving a circuit’s signal behavior from its schematic. 

Intentional analysis. 

Intentional analysis automatically falls out of the statement of circuit correctness 
It allows a verifier to concentrate solely on the behavior of a design that contributes 
to the design s behavior at the higher levels of abstraction. 


A Constraint System. 


The constraint system serves a dual role. The constraints themselves serve as part 
of the proof that a given circuit will exhibit its intended digital behavior. Their 
other role is the mechanism by which very large circuits are verified. 


Accurate models. 


Verification would be meaningless if there were large classes of bugs which 

be modelled. This research uses component models capable of modeling 
circuit bugs. 6 


could not 
common 
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An existence proof that the theory works. 

Silica Pithecus is proof that a verifier with an accurate circuit model can be made 
to run, and run quickly, for large circuits. 


1.6 Organization of the Thesis 

This dissertation has four major chunks: the circuit model (Chapter 2), the theory 
of multilevel verification (Chapters 3 through 5), the structure of Silica Pithecus 
Chapters 6 through 9), and the theory and practice of hierarchical verification 
(Chapters 10 and 11). An annotated chapter listing appears below. 

Chapter 1, Introduction 

This chapter delineates issues, presents an example, introduces terminology 
summarizes results, and presents an annotated chapter listing. 

Chapter 2, Component, Signal, and Network Models 

Chapter 2 presents Silica Pithecus’s component, signal, and network model, 
ifie signal model describes the primitive elements manipulated by circuits. The 
component model describes the primitive devices for manipulating signals. The 
network model describes what the meaning of interconnected components is. An 
analogy can be made between circuits and programming languages, where signals 

correspond to primitive data types, components correspond to primitive operations, 
and programs. 

Chapter 3, Multilevel Verification 

There are many different levels of description (e.g., signal, digital, functional) of 
a circuit s behavior. Multilevel verification is defined as proving that two different 
evels of description describe the same behavior. The lower level of behavioral 
description of a circuit’s behavior is the circuit’s concrete behavior, the higher 
level description is its abstract behavior. Chapter 3 presents the formal basis of 
multilevel verification. It presents examples of both of verifying a circuit’s signal 

ehavior against its digital behavior, and of verifying a circuit’s digital behavior 
against its functional behavior. 

Chapter 4, Time and State 

Chapter 4 discusses how state and time are incorporated into the formal model 
of the previous chapter. The major result of Chapter 4 is method for symbolically 
predicting the final state of a circuit solely from its initial state and inputs. The 
prediction does not perform a simulation of any kind. 

Chapter 5, Non-electrically Isolated Inputs 

Chapter 5 extends the theory of Chapters 3 and 4 to include circuits with non- 
electncally isolated inputs. 

Chapter 6, Silica Pithecus 
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Silir 7~ ° f 1Ca Pl ‘ hecus 18 Presented in Chapter 6. The major parts of 

77 a “* dls< i msed in tha n «‘ chapters. Parts of Silica Pithecus 

h.ch do not deserve their own chapters appear in Chapter 6. This includes the 
representation of circuits and Silica Pithecus’s comparison methods. 

Chapter 7, The Specification of Digital Systems 

A Jn he “7 7 specif >™ g both digital beh »™c a nd digital systems is discussed, 
an 7777“ th<! sp “ lficatlon of digital systems is presented. This language has 
nterpreter so specifications can be debugged by executing them. 

Chapter 8, Generating Net Behavior 

diffemnt b n e . h tr t r. iS ‘ reputation of a circuit that emphasizes the 

an algorithm for “ t m ' 8 “““h” ° f d “ ri ” g Settling ' Chapter 8 presents 

an algorithm for generating net behavior. 

Chapter 9, From Net Behavior to Digital Behavior 

behavim'to'^d-Tn'“ Tf • behaVi ° r fr ° m net behavior “ d th “ “bstract signal 
Chanter 7 **7 T.’ “ 15 more efflcient to generate digital behavior directly. 
Chapter 9 discusses how the network model is invoked to interpret nets and how 
the interpretation is abstracted to the digital domain. 

Chapter 10, Hierarchical Verification 

verificaVnnT 7 “ d 7777 hierarchical verification and hierarchical multilevel 
verification is presented in Chapter 10. 

Chapter 11, Processing Constraints. 

how thw P ^^ 6CUS USG ® ^ ve types constraints. Each of these constraints and 
7 pr ° CeSSed 13 presented in Chapter 11. The preliminary processing 
Drove™ “ ldentlCa1 ’ but each ty P e of constraint has it own special theorem 

pruverSt 

Chapter 12, Future Research 

• Cbapter r 12 discusses problems I never got around to solving. This includes 
using the information needed for verification to create an accurate timing estima- 

aLractioZnc"tns Wi ‘ h “ paCiUve “ uplipg - a " d ”““‘ p ' a 



Chapter 2 

Component and Signed Models 


* n °o * Urn our attention to the signal, component, and network models used by 
bihca Pithecus. This modularization corresponds to describing the semantics of a 
programming language m terms of its primitive data types, primitive operations on 

these types, and what the meaning of a combination of primitive operations (called 
a program) is. v 

The component model used by Silica Pithecus is as accurate as the component 
model used by any large scale simulator. 1 Silica Pithecus’s component model is 
superior to OSSIM s model, and, not counting modeling how long a circuit takes 

rctL 6 ’ 1S . supenor to RSIM ’ s model. To a first approximation, if MOSSIM or 
KbIM can simulate a circuit, then Silica Pithecus can verify it. 2 

Silica Pithecus could employ a simpler model than it does, such as MOSSIM’s 
switch level model This would save some analysis time. However, the time savings 
would not be worth the less accurate verification that would result. For example, 

MOSsf^s" ^ ^ aWe d6teCt “ ra,i ° »““ if « 

This chapter has five sections. The first section describes Silica Pithecus’s com- 
ponent model. A new way of describing circuit a circuit’s dynamic structure, called 
net behavior, is presented in the second section. The third section describes Silica 
Pithecus s network model, that is, what interconnected components mean. Silica 
Pithecus s signal model is described in the fourth section. A discussion of the bugs 
which can and cannot be modelled are presented in the fifth section. 

A large scale simulator is a simulator that handles circuits in excess of 10,000 transistors. 

2 This statement is only partially true, as Silica Pithecus won’t verify circuits that use unclocked 
U is t“t. ^ n °‘ * aWe t0 PrOVC 8 ° me COTTeCt CirCUit8 « 
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2.1 The Component Model 

Silica Pithecus uses a component and network model similar to RSIM’s model [Ter- 
man] except for RSIM’s features which are concerned solely with timing. For exam- 
p e, there is only one effective resistance for any given transistor, rather than three. 
We will first describe transistors, then nodes. 


Transistors 

Conducting transistors are modelled as resistors in series with a threshold drop 
dernce. The resistance of a transistor 3 depends on the gate voltage of the transistor 
and the channel length and width of the transistor. A threshold drop device appears 
m circuit diagrams as a square with an X in it. 

The resistance depends on three factors: 


1. Length and Width: The resistance of a transistor is proportional to its 
channel length divided by its channel width. 

2. Type: The type of a transistor determines the resistance of a unit square of 
the active region. 


3. 


Gate Voltage: 
threshold drop. 


The resistance is doubled if the gate voltage has suffered a 


Silica Pithecus’s model for an enhancement mode transistor divides a transistor 
into four operating regions (Figure 2.1). The X’d square represents a threshold 
rop evice. This device acts as a regulator preventing more than a certain amount 
° < T ar ® e ( electr ° ns ) from being pushed through it. For example, in the third case 
of the figure only enough charge can be pushed through it to raise the voltage 
on the node to its right to 3.5 volts. When the gate voltage is between 1.5 volts 
and 3.5 volts the resistance of the transistor is unknown (denoted X). A depletion 

droffdevice ^ “ * resist ° r ° f resistance L/W with no concomitant threshold 

This is a simple transistor model. There are many real phenomena it ignores or 
simplifies. Nonetheless, the model is accurate enough for our needs. 

There is nothing sacred about our choice of voltages. We have chosen the upper 
rail as 5 volts and the lower rail as 0 volts for convenience. These voltages could have 
been left symbolic (we will sometimes write them as Vdd and Gnd, respectively) 
however, this wouldn’t have change the results or theories of this dissertation. 

3 More accurately: “the resistance of the resistor the transistor is modelled as.* 
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nMOS Transistor 



L/W 


voltage(G) < 1 .5 ==> 



1.5 < = voltage(G) < 3.5 

3.5 < = voltage(G) < 5 
5 = voltage(G) = = > 



Figure 2.1: Silica Pithecus’s Transistor Model. Enhancement transistors are mod¬ 
elled as resistors in senes with a voltage controlled switch. The resistance of the 
transistor depends on the gate voltage. When the gate voltage is low enough 
then th® transistor is modelled as an open switch. When the gate voltage is “full 
strength the resistance of a transistor is L/W where L is the channel length and W 
1S the channel width The resistance is doubled when the gate voltage has suffered 
a threshold drop. The X’d square represents a threshold drop device. This device 
acts as a regulator preventing more than a certain amount of charge (electrons) 
from being pushed through it. For example, in the third case above only enough 
Ch f/ ge ~ n be pushed through it to raise the voltage on the node to its right to 3.5 
volts. When the gate voltage is between 1.5 volts and 3.5 volts the resistance of the 
ransistor is unknown (denoted X). Depletion transistors are modelled as resistors 
ol resistance L/W with no concomitant threshold drop device. 
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Figure 2.2: A Latched Inverter Cell. This cell differs from 
the placement of the latch gate. 


an Inverting Latch by 


Nodes 

Silica Pithecus models nodes as capacitors to Ground. Capacitance is measured in 
dimensionless units. (When timing is a concern, capacitance needs proper units.) 
Nodes whose capacitance is not declared have a capacitance of 1 


2.2 Net Behavior 

D n n ? g .u ettlii : g , a n ° de is a member of man y different nets. The different nets are 
called the node s possible nets. Depending on the pattern of conducting transistors 

and the topology of the circuit, the sizes of a node’s possible nets can range from 
containing a single node (the node itself), to containing every node in the circuit. 
A node s possible nets and the conditions under which they are active is called the 
nodes net behavior. Net behavior is a function that maps time into nets. Given 
some time t, the net behavior of node N returns the net that N is a member of at 
t. A circuit s net behavior is the sum of its node’s net behaviors. 

For example, consider a Latched Inverter Cell (Figure 2.2). 4 The S node of this 
device has three possible nets, which are shown in Figure 2.3. The net on the left, 
the single node S, arises when Latch* is not asserted. The middle net occurs when 

Lately is asserted and In* is not asserted. The net on the left arises when both 
Latch* and In* are asserted. 

We will use a textual notation for nets: if a net contains nodes A, B, and C, 
hen it is textually written [A, B, CJ. For example, the abbreviations of the nets of 
Figure 2.3 are [S], [S, Vdd, Out), and [S, Vdd, Out, Gnd], respectively. 

4 A Latelied Inverter Cell differs from an Inverting Latch (Figure 1.3) by the placement of the latch 
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Figure 2.3: Possible Nets of the S Node of the Latched Inverter Cell. 


urrent doesn t flow between nets. This has two intertwined benefits. First, 
net behavior is a wedge by which we can modularize a circuit’s behavior to make 
analysis possible. Second, all the possible sources of change to a node’s voltage 
are contained in the node’s possible nets. Therefore a node’s voltage over time can 
be predicted by analyzing the node’s net behavior. (This analysis is presented in 


2.2.1 


Representing Net Behavior 


A node N s net behavior is represented by a net behavior expression written as 
McCar hy conditional (Lisp 1.5]. The conditional consists of a series of clauses. 
Each clause consists of one predicate and one net. The predicate is a boolean 
expression If a predicate is true then N is a member of the predicate’s associated 
net. denotes N s net behavior. 

For example, consider again the S node of the Latched Inverter Cell (Figure 2.2). 
The representation of its net behavior is 


s n«t = A t . Latch* (t) A In 4 (t) -► [S Vdd Out Gnd], 
Latch* (t) A N0T(In*(t)) -+ [S Vdd Out]’, 
NOT(Latch*(t)) - [Sj 


This formula is called a net behavior equation. The left hand side of a net behavior 

equation is the name of a node subscripted by net and the right hand side is a net 
behavior expression. 

The net behavior of a circuit is a listing of the behavior equations of its nodes. 
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source^* — At. gatej(t)—► [source drain], 

N0T(gate 6 (t)) —► [source] 
drain^t = A t . gate 4 (t)—► [source drain], 

N0T(gate 4 (t)) —*• [drain] 
g ate n«t = A t. [gate] 

Table 2.1: Net Behavior Equations of the nMOS Transistor 


For example, the net behavior of an n-channel transistor has three equations, one 
for each node (Table 2.1). 

Efficiently finding the possible nets in a circuit requires understanding the logical 
structure of a design, which signals are mutually exclusive and how some signals 
depend on other signals. Without this knowledge a circuit can appear to have an 
exponential number of nets with respect the number of transistors in the circuit, 
rather than the linear or quadratic number of nets intended by the designer. For 
example, a barrel shifter’s control signals are mutually exclusive. Therefore, it has 
only a linear number of nets. But unless this knowledge is used, the barrel shifter 
will appear to have an exponential number of nets. Chapter 8 discusses the methods 
of employing the logical structure of a design during circuit analysis. 

We now introduce a some terminology that is used throughout this dissertation. 

-chip inputs (e.g., Vdd, Gnd, clocks) are assumed to be driven and are called 
driven nodes. Nets containing at least one driven node are called driven nets. All 
other nodes and nets are called undriven. What others have called a storage node 
we treat as a degenerate case of an undriven net containing only one node. A net 
contracts when some transistor in it shuts off thereby partitioning the net into two 

smaller nets. A net expands when one of its boundary transistor turns on thereby 
connecting it with some other net. 


2.3 The Signal Model 

Silica Pithecus models signals as functions which map time into a voltage and a 
strength. That is, 6 

Signal: time —► voltage x strength. 

Intuitively, a signal is what we see on our oscilloscope when we probe one of the 
nodes of the circuit and watch the circuit in operation. Signals have two compo¬ 
nents, voltage and strength. The voltage of a signal is well understood and will not 
be explained. Signal strength is explained below. 
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strength(y) = n m 
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strength(y) * n 



strength(y) * infinity 


Figure 2.4: Signal Strength 


2.3.1 Signal Strength 

Signals emanate from nets of nodes (hereafter just called nets). The strength of 
a signal at some point in time is the the sum of the capacitances of the nodes in 
the net from which the signal emanates at that point in time. Driven nodes are 
considered to have infinite capacitance. 

For example, consider the simple circuit of Figure 2.4. Assume that there is 
probe at node Y. We are going to measure the strength of Y„ the signal at Y, for 
different states of the circuit. When all the transistors are off, the strength of Y, is 
n. If Bis then asserted, the strength of Y, goes ton + m. Asserting A at this point 
causes Y, s strength to be oo because the “capacitance” of VDD is oo. A signal 
whose strength is oo is a called a driven signal. 

The strength waveform of a signal 5 at a node encodes the charge sharing pat¬ 
tern of the node An increase in X.’s strength indicates X is increasing the number 
of nodes with which it shares charge. A decrease in strength indicates that X is 
decreasing the number of nodes with which it is sharing charge. Knowing that a 
signals strength only decreases or only increases during a computation is very valu¬ 
able. For example, when a signal’s strength only decreases during a computation 
then the nodes in the signal’s final net retain their initial charge. Chapter 4, which 
shows how a circuit’s fina l state is predicted, discusses the strength of signals in 

A strength waveform is analogous to a voltage waveform. It is a plot of strength versus time. 
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voltage 



strength 



t. 


I 


time 


Figure 2.5: Notation for Time. We assume that a circuit is at steady state when its 
inputs change By convention, f, is the time at which the first input changes and t, 
is the time when the circuit settles again. 1 


detail. 


2.3.2 Notation for Talking about Time 


We assume that a circuit starts out at steady state, that its inputs change, and 
that the circuit then settles to a new steady state. We call the change of an input 

reo C rst Tr n ,- e9UM l and , that * drCUit is CaUSed to * * computation 

request. The time when the inputs first change is called the initial time and is 

denoted f,-. The final time, denoted, t h occurs when the circuit achieves steady 
state. These times are illustrated graphically in Figure 2.5. 

As a consequent of this notation X.(t.) denotes the value of X. before a compu¬ 
tation requ«t is issued. denotes the value of X, when the circuit settles. A 

signa is stable during a computation request R (i.e„ from the time R starts to the 

time the circuit settles) if and only if the signal provably never changes during this 
time. 


Nnet(ti) is called N’s initial net. N is called the N’s 
Following standard nomenclature, the predicates which select 
final nets are called the node’s precondition and postcondition , 


final or chosen net. 
a node’s initial and 
respectively. 
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2.4 The Network Model 


iven a net of transistors and a node of interest, the network model says how the net 
is interpreted to yield a voltage and a strength at the node. Thevenin equivalents 
are used to interpret net containing driven (*.«., off-chip) nodes. A charge sharing 
model is used for nets not containing driven nodes. 

The final voltage of a node N in a net containing driven nodes is determined 
by creating the Thevenin equivalent of the net regarding N as the net’s output. 
The calculation is similar to the calculation presented by [Termanl, except that 
intervals are not used in the calculation. The subnet “above” the node (i.e., the 
subnet leading to Vdd) and the subnet “below” the node (».«., the subnet leading 
to Gnd) which form the voltage divider for the node are each reduced to yield 
characteristic voltages. It may be the case that there is no subnet “below” the 
node, in which case the node is pulled-up. 


An example of creating an equivalent voltage divider appears in Figure 2.6. In 
this example a net with two transistors above the output node and two transistors 
below the output node are replaced by one equivalent transistor above the output 
node and one equivalent transistor below the output node. 

Final voltages cannot be determined for nets not containing driven nodes because 
he verifier can t know the charge on the nodes in the net. Instead, Silica Pithecus 
locates a dominant node whose capacitance is sufficiently greater (more than 10 
times) than the sum of the capacitances of all the other nodes in the net. If such a 
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node exists, then all the nodes in the net will 
node. 


assume the voltage of the dominant 


error ^ cT "o- ^ the " SUi “ PithKUS wHI » <*M*«haring 

r. (Of course, Silica Pithecus is careful only to generate such errors for nets 
which must yield a valid voltage.) 


2.5 Bugs Modelled and Not Modelled 

We first discuss bugs that can be caught, then bugs that can’t be caught. 

2.5.1 Bugs Modelled 

The bugs that can be modelled are listed below. 


harge Sharing A charge charging bug occurs when two or more nets share 
charge but neither has sufficient charge to “overpower” the other thereby re¬ 
sulting m invalid voltage levels. Circuit techniques such as precharged buses 
can be verified only by a system that properly models nodes. A verification 
system which modelled all nodes as having the same capacitance could not 
verify a circuit which used precharged nodes. 

Ratio Bugs A gate in an nMOS circuit is a voltage divider. A gate is capable 
Of driving its output to the upper rail, but incapable driving its output to 
the ground level. (Because that would imply that the pulldown has zero 
resistance.) The resistances of the two “halves” of the voltage divider must 
be carefully balanced to ensure that the output is close enough to ground 
to ensure a reliable zero level, but not so close that that the current flow 
through the gate is excessive. Ratio bugs can be modelled because transistors 
are modelled as resistors whose resistance is dependent upon the geometric 
characteristics of the transistors. 


Threshold Bugs Transistors are not ideal switches. Transistors can only pass a 
certain voltage that is some fixed amount below the voltage on their gates. 
As signals pass through pass transistors they suffer threshold drops which is 
exhibited as a truncation of a signal’s voltage. There are two different types of 
bugs caused by threshold drops. The first is ratio problems with gates because 
the resistance of a transistor depends upon its gate voltage (Figure 2.7). The 
second is threshold drops adding up when a signal suffering a threshold drop 
gates a transistor T causing the signal gated by T to suffer two threshold 
drops. Signals which suffer two threshold drops have lost enough voltage to 
become invalid signals. Threshold drops are modelled by including an explicit 
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Out 


Figure 2.7: Two Differently Sized Inverters. The minimum-sized inverter does not 
work tor all inputs that the nonminimum inverter works for. It will only work if 
Its input has not suffered a threshold drop. The nonminimum inverter works for a 

greater range of inputs at the cost of using more area and being slower than the 
minimum sized inverter. 


threshold drop device in the transistor models. Other systems, 
have not modelled threshold drops. 


t.g., RSIM, 


Races A race occurs between two signals when the final state of circuit is a function 
of which signal changes first. Often the proper operation of a circuit requires 
that when a race happens, one of the two signals always changes first. Races 
can be modelled because the signal model explicitly includes time. Some 
systems, such as MOSSYM, do not model time, and therefore can’t detect 


Hazards Hazards can be considered as degenerate cases of races where a signal is 
racing with itself. A hazard occurs when a circuit can detect the number of 
transitions a signal has during settling. For example, if a signal begins and 
ends at zero, but the circuit it’s in has a different final state depending on 
whether the signal has zero or two transitions, then a hazard occurs when the 
signal goes through two transitions. 


2.5.2 Bugs Not Modelled 

Bugs which can't be modelled by Silica Pithecus are those arising from unanticipated 
capacitive coupling and spikes on off-chip inputs. 

Ignoring Capacitive Coupling 

Capacitive coupling is ignored so that number and size of a node’s possible nets 
is minimized. If capacitive coupling were modeled, then nets would span the chip 
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Drain 

Gate / j 




C ^1 

Source 


Figure 2.8: MOS transistor symbol with explicit C gt and C gd . 


a nd the circuit would have to be analyzed monolithically. 6 This analysis would be 
infeasible for even moderately sized circuits. In this section I show the sources of 
capacitive coupling, discuss the drawbacks in ignoring it. 

' WO ™ in “"“of «P»citive coupling arc the gate to eource capacitance 
of MOS transistors, and the coupling of physically close wires. The dominant source 
is the capacitance of transistors, by far. 

A M OS n-channel transistor is modelled in detail as having a capacitor between 
its gate and source (Figure 2.8) and between its gate and drain. This capacitance 
can be increased by the inclusion of an explicit capacitor. This capacitor forms a 

coupling between the gate and source nodes of the transistor through which current 
can now. 

There are two undesirable effects of ignoring coupling capacitance: not being 
able to model anticipated capacitive coupling, and not being able to catch bugs 
arising from unanticipated capacitive coupling. The first undesirable effect, not 
being able to model circuits which depend on capacitive coupling can be overcome 
by making such circuits primitives of the design system. They can then be treated 
specially, as other primitives («.</., transistors) are. For example, bootstrap drivers 
coidd be treated this way. No other large scale analysis system U.g., TV [TV 
°uppi], MOSSIM [Bryant8l], RSIM [Terman], Crystal (OusterhoutJ) has handled 
capacitive coupling in a general way. For example, [TermanJ does a prescan of 
the circuit which recognizes boo tstrap drivers and replaces them with primitive 

s There is no way within my framework for heuristically examining only those parts of the circuit 

HZZ'T'ZVr* effec ; s "• 3ignificant - Th ‘« are -asons for this First, I am tX 
inclusion" m, 30 • . a 1 ca “ make clear statements about what it means to verify a circuit. The 

o Ldkate l T“f S,"* ■' T L * h “ SOil SeCOnit therc “ no clean mechaniL for a designer 

mdicate parts of the circuit which bear closer inspection by the verifier. 
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elements. Other than ad hoc checks, there does not seem to anything that can 
coupling ab ° Ut the inabilIty t0 Catch bugs arisin 8 from unanticipated capacitive 


No Loads on Off-chip Inputs 

Charge retention analysis does not model wavering off-chip inputs; there are no 
edges in a net transition graph corresponding to off-chip inputs which suddenly un¬ 
dergo large loads. Therefore off-chip inputs must be considered immune to on-chip 
transitions. For example, Gnd and VDD are considered constant; even if a heavy 
load is placed on them this load cannot be detected anywhere in the circuit. The 
same is true for the other off-chip inputs. I do not know if this is a significant prob- 
ern for MOS circuits (*.«., if circuits have failed because designers didn’t anticipate 
oads causing off-chip inputs to waver), but I know of no system which addresses 


2.6 Summary 

This chapter presented the the component model, signal model, and network model 
of bilica Pithecus. These models are known collectively as a circuit model. The 
bugs which can and can’t be modelled within this model were discussed. 

This chapter introduced the notion of net behavior. The idea of focusing analysis 
on nodes and the nets they are members of during settling is novel. Previous 
researchers have looked at the nets a circuit is partitioned into during settling 
without investigating what the partitioning looks like from a node’s point of view. 
The power of this idea in the next chapter appears in the next chapter. 




r- 









Chapter 3 

Multilevel Verification 


Circuit behavior can be described at different levels of abstraction ranging from the 
analog level to the functional level. Multilevel verification proves that two different 
levels of behavioral description describe the same behavior. The more abstract level 
description of a design’s behavior is called its abstract behavior , the less abstract 
level description of a design’s behavior is called its concrete behavior. 

Multilevel verification has two parts: abstraction and validation. Abstraction 
lifts the concrete behavior level to the abstract behavior level. The resulting de¬ 
scription is called the abstracted behavior. Validation is the comparison of the 
abstracted and abstract behaviors. An implementation meets its specification if the 
comparison succeeds, otherwise the implementation is declared incorrect. 

This two step scheme, abstraction followed by validation, makes the dependence 
of verification on the abstraction function explicit. The abstraction function serves 
two purposes: approximation and structure definition. Which purpose is served 
depends on the descriptive level of the concrete behavior. At the lower levels, such 
as the signal level, abstraction replaces “physical reality” with gross approximations 
[t.e., digital values). At this level, the accuracy of verification is bounded by the 
accuracy of the abstraction function. For higher descriptive levels, such as the 
digital level, abstraction replaces data structures with the values they denote. For 
example, when abstracting from the boolean level to the arithmetic level, a vector 
of booleans is abstracted to a number. 

• Not L\ U eIements of the concrete domain map into elements of the abstract do¬ 
main. The abstraction function is responsible for returning an error value on ele¬ 
ments which do not map. For example, the abstraction of a signal that can not be 
abstracted to either 0 or 1 must be an error value. One role of constraints is to 
specify that a design’s inputs and outputs are always abstractable. For example, 
at the signal level, the constraints such as no-drop, falls-first, overpowers, 

and control all exist solely to ensure that input and output signals abstract to 
non-error values. 
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The difficulty of validation depends on the descriptive level. Digital validation 
consists of proving two digital expressions are equivalent. Except for complex com¬ 
binational circuits such as ripple carry adders, the formulas are small and easily 
compared. Functional validation, which must compare formulas in domains richer 
than boolean algebra ( e.g ., arithmetic), is hard to do. 

V 6 !! 8 ? I 8 di9i !f y Verifi * d When its si * nal be havior has been verified against 
its intended digital behavior. Likewise, a design is functionally verified when its 

digital behavior has been verified against its intended functional behavior. We 

are primarily concerned with digital verification. The methods to be proposed for 

7 en A Catl ° n have been im P leme nted, but no such claim is made for proposed 
methods of functional verification. 

. ^ J m , aj ? r advantage of mult ilevel verification is that the description of the in¬ 
tended behavior itself can be verified. Abstract behavior at one level is concrete 
behavior at the next abstraction level up and can itself be verified. This is a powerful 
mechamsm for verifying the behavior of a design over many levels of description. 
This chapter has four sections. In the first section some of the levels of behav- 

10 /f. deSCnpt . 10 ? are discussed * A brief discussion of the different descriptive levels 
of time is included in the first section. The second section describes multilevel ver- 
lhcation. It delineates issues and presents my theory of multilevel verification. The 

third section focuses on digital verification and functional verification. The chapter 
concludes with a s ummar y, H 

h a glV ™“ Can he , described in a variet y of ways. For example, a circuit can 
be described at the signal, digital, gate, or functional level. Each level hides details 
e lower level. A pictorial example appears in Figure 1.1. The higher levels of 
description are more concise than the lower levels. 

We are concerned with the signal, digital, and, to some degree, functional de- 
scnptions of circuits. The signal level describes a circuit’s function in terms its 
input and output signals. The digital level is similar to the boolean level, but with 

the ^elusion of the operand float and the function join. The functional level is 
defined by the user. 

The signal level views a circuit as a map from input signals to output signals. 
The signals at state nodes are both input signals and output signals. A signal is what 
appears on your oscilloscope when you stick the probe on a node. It is crucial that 
signals, rather than voltages at some point in time, are employed as the primitive 
values operated on by circuits. Signals encompass time, therefore any method for 
abstracting signals into digital values must consider time. 2 If just voltage at some 
point m time were used, then a separate mechanism would be required to handle 
time. A separate mechanism wo uld make the formalization of verification much 

1 J. h# di ?« rent descriptive levels do not form a linear hierarchy. For example, a digital design that 
uses tristate buses cannot be abstracted to the gate level. 

3 Even if an abstraction function ignores time, it must do so explicitly. 
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harder. The following chapters discuss in detail the derivation of a circuit’s signal 
behavior from its structure. 

The digital level has three primitive values: 0, 1, (called boolean values) and 
float. It has the standard boolean functions for operating on boolean values and 
the operator j oin. Join is an n-ary function which returns float if all its arguments 
are float, returns 1 if all the non -float values are 1, returns 0 if all the no n-float 
values are 0, and otherwise signals an error. Join and float are used to model 
circuits containing tristate devices. 3 

The functional descriptive level is very abstract. Its primitive types and op¬ 
erations are defined by the user. For example, the primitives may be numbers, 
pointers, or sets. The corresponding operations might be addition, dereferencing 
or union. This level is characterized by being very close to the application the de-* 

signer is creating a circuit for. Specifying the behavior of a circuit at this level is 
very concise and simple. 


3.1 A Formal Model of Verification 

We first introduce notation. Design is the object whose behavior is to be verified. 
Its behavior^in some domain D is written B D (Design). Design’s inputs are are 
wri en t D - t lD ,...,t no where t D € D n . Its outputs are the result of applying 

.ts behavior to its inputs: o D = B 0 (De,ign)[i D ) = ... where b D £ D« 

ihe two domains of a given multilevel verification are called con and abs. Multi¬ 
level verification relates B con (Design) and B aht (Design). We will often leave the 
domain descriptor off the inputs and outputs and just write * and 6. When domain 
descriptors are elided the con domain is assumed. 

SPEC, the specification of Design, is what it to be proved about Design* P 
are the set of promises about how the design will be used, they restrict the class of 
allowable inputs to Design. P corresponds to what we have been calling constraints 
Design is verified with respect to its specification SPEC and constraints P when 
the verification condition 

A p(*)) ^ SPEC(i,Bo(Design)(i))} 

pep 


is shown to hold. 


The hardware digital level is the abstraction level espoused in Introduction to VLSI Systems 
Lartt /n TT 1 ' u ? b PrOV ! de8 a methodol °8y of design (i.e., approved ways of connecting 

fromth^rhn r i u Pr ? CrVeS th " digital ab8traction - F or sample, a designer who learned only 
from their book would not create a bootstrap driver (Figure 12.1) or a three transistor ram (Figure 

'SPEC has a very specific form when multilevel verification is performed, as will be seen below. 
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• Design is a circuit with one input * and one output o ranging over time-varying 
signals S. Bs(Design) : S S 


i 


Design 


o 


> 


Vi<=s{stable(i) => stable(o)} 

• Design is a nand gate. 


il 


1 - 

\2 


o 


^•'i.«j€{frue,/alje}{*2 ^ (o — not(li))} 

• Design is an adder whose inputs t and output o range over the natural num¬ 
bers N . In this example P is empty. 


11 

12 


o 


= *1 + *2} 


Figure 3.1: Example Verification Conditions. These are all examples of monolevel 
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Examples of verification conditions are shown in Figure 3.1. The first example 
checks properties about signals in to and out of a circuit. It specifies that if the 
input signal is stable then so is the output signal. The next example is the statement 
that if you hold one of the inputs to a nand gate high then the gate looks like an 

inverter to the other input. The third example is the statement that some device 
is an adder. 

All of these are examples of what we call monoltvtl verification. In monolevel 
verification only one level of behavioral description is handled. Monolevel verifica¬ 
tion attempts to prove specific properties of the behavior of a device. 


Multilevel Verification 

In multilevel verification there are two different levels of description for Design, 
Bcon(Design) and B aht (Design), which must be related. The relationship between 
the two domains is given the by abstraction function ABS. It maps elements of con 
into elements of abs. There are some elements of con for which ABS is undefined. 
We make ABS a total function on con by adjoining a special “error element” _L, to 
ABS's range as a target for ABS when it would otherwise be undefined. Specifically, 
ABS : con => abs + {!_}. ABS is defined for some input * when ABS(i) € abs. 
Any element of con for which ABS returns _L is said to be invalid. 

When discussing specific domains, ABS may be subscripted with its types. 
For example, when the context isn’t clear, the abstraction function from signals 
5 to tristate values T will be written ABS s _ T . Finally, we also have ABS(i) = 
A-BS(i'i), • • • ,ABS(i n ) 

Given B eon (Design) and ABS, B abt (Design) is projected from B eon (Dcsign ) by 
the following formula: 

con n {ABS(B eon (Design)(i)) = B a *,(Dest 0 n)(ABS(i))} 
wherever ABS(i) and ABS(B eon (Desi 5 m)(t)) are both defined. 

This relationship can be expressed as a commutative diagram (Figure 3 . 2 ). The 
key point is that B abt (Design) does not exist independently of ABS. For example, 
if ABS returns _L everywhere, then B abt (Design) is nowhere defined. 

We can now define multilevel verification. Given B eon (Design) and of De¬ 
signs intended abstract behavior IB abt (Design), we wish to show IB abt (Design) = 
B abt (Design): 

Definition: Multilevel Verification is Verification where the specification is of the 
form 

ABS(B eon (Design) (i e(m )) = J£ a 6 ,(DMi>n)(ABS(i e<m )). 

where IB abt (Design) is the intended abs level behavior of Design and where both 
sides of the equation are defined. 



58 


CHAPTER 3. MULTILEVEL VERIFICATION 


A 

i 


abs 


ABS 


A 

I 


con 


Babs (Design) 


A 

-► o 


abs 


ABS 


A 

O 


B cori (Design) 


con 


I II *? B Th ,V °' U !l‘ P , between B cm (D',ign) and B*,(Dcsign). Given 
ine *h- B rr^ Des,9n ^' B ^(Dt3ign) ia projected from B, m (Dcsign) accord- 

ARSiB h !n d '* gr ^' u h * C J °™ tativity nMd onl y hold when ABS(i con ) and 
ABS(5 ct)n (Z)cst^n)(t ( . on )) are defined. 


Putting everything together yields 

Viecon-M P(») => ABS(B con (Z)estyn)(i)) = IB abt (Design )(ABS (?))} 

as the verification condition for multilevel verification. 


The Role of P, and Automatically Generating Constraints 

An important part of the above proposition are the promises P, also called con- 
thre^roleT- ^ daSS ° f allowable in Puts to a design. The constraints have 


1. To ensure valid inputs (U., that ABS(t con ) is defined). These are called input 
constraints and are assumed to be met. 

2 . To ensure valid outputs (i.e., that ABS(B^(Dcsign)(i„ n )) is defined). These 
are called output constraints and can be automatically generated. 

3. To specialize behavior. These are called logical constraints and must be pro- 
vided by the designer. 
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Input constraints are assumed to be met by the environment in which a design 
operates. Inputs are assumed to be valid because they either come from the outside 
world in wh^h case we must assume they are valid, or they are outputs from other 
verified designs, which guarantees they are valid. For example, consider a circuit. 
Only inputs from off-chip must be assumed to be valid, all other inputs are valid 
because they are outputs of verified subcircuits. 


The constraints which ensure outputs are valid can be automatically generated. 
Given a representation of ABS^* (£«.>») (I*,)) that makes error conditions ex¬ 
plicit, constraints are generated which ensure the conditions causing the error condi¬ 
tions never arise. For example, in the signal domain, this how threshold constraints 
are generated. When an input signal suffering a threshold drop causes an invalid 
output signal the signal will be constrained from suffering a threshold drop. The 
constraint guarantees the output will not be invalid (at least from this particular 
causej. An explicit example is presented below. 

The constraints which specialize the behavior of a design must be provided by 
e designer. They cannot be assumed or automatically generated. For example, 
the logical constraints a designer must provide to Silica Pithecus to declare certain 
inputs are mutually exclusive. The constraints specializing behavior must be em- 
p oyed when deriving a design’s behavior from its structure. Otherwise, behaviors 
which don t arise will be predicted. 


The Big Picture 

Three major ideas lurk in the verification condition for multilevel verification. They 

a re* * 


• The relationship between different behavioral descriptions. 

• The relationship between structure, function, and context. 

• Intentional analysis. 


The first item, the relationship between two different behavioral descriptions 
has been discussed in detail. 

The introduction of this dissertation made the claim that structure alone does 
not determine function, but that structure and context do. Referring to the ver¬ 
ification condition of multilevel verification, we can now state more precisely the 
relationship be structure, function, and context: P is the context that the structure 
Design must have to exhibit behavior IB ab ,(Design). 

Intentional analysis says that what must be derived from a design’s structure is 
not its behavior, but the abstraction of that behavior. That is, the important item 
is not B eon (Dcstgn), but ABS(B con (Design)(t eon )). As a result, the full behavior of 
Design need not be generated. For example, the focus of Silica Pithecus’s behavior 
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generation is not to generate signal behavior, but to generate constraints which 
ensure that whatever the signal behavior is, it will be abstractable. Much of the 
signal behavior is left symbolic (».«., in terms of the names of signals rather than 
the signal values themselves). 

We now look at functional and digital verification in detail. Functional verifica- 
lon will be presented first to get the reader accustomed to the ideas and notations. 


3.2 Functional Verification 

The application of the design (e.g., numbers, sets, pointers) determines the type of 
abstraction and functional validation. A given design may support many domains 
at once. There are two major problems associated with functional verification: 
validation and accurate specification. In the following we will concentrate on just 
the arithmetic domain (integers and addition) to illustrate functional verification. 

Validation, the comparison of abstracted functional behavior and intended func- 
tiona behavior, is difficult to do. A significant amount of knowledge of the func- 
tional domain must be employed . 5 Embedding in a verifier the knowledge needed 

1S V. a j d I beCaUSe !t 18 hard to ° priori determine which knowledge will be useful: 
embedding everything is virtually impossible. 

The second problem with functional verification is accurately specifying be- 
aviors. A specification must be well defined before validation can be done. For 
example, consider the digital specification of a 16 bit adder for adding unsigned 
..integers, called A and B. Each integer is represented as vectors of bits (the stan¬ 
dard representation). There are several choices possible for handling overflow. The 
overflow bit can be ignored, it can be appended to the sum to yield a 17 bit result 
or it can be returned separately to signal an error condition. 

Even though each of the three methods of handling the overflow bits still results 
in an adder, only one, the second, can be specified as A + B (for A,B < 2 16 ). 
The others, which are far more common, must be specified differently, for example,’ 

•fi + *- m ° d 2 f ° r th ® first method - (There’s even residual vagueness in the spec¬ 
ifications given. The function ♦ is polymorphic, its behavior depends on the types 
of its operands. A more accurate specification is A +,•„* B and (A + int B) mod 2 16 .) 

Example: An Adder Cell 

Consider a full adder (Figure 3.3). It has three inputs A, B, and Carryin, and 
two outputs called Carryout and Sum. The Adder Cell is composed of gates, 
therefore its concrete behavior is expressed in the boolean domain. We with to 
show the adder cell adds number s, therefore its abstract behavior is expressed in 

5 Also, these domains are very complex and formulas in them may be undecidable. 
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A 



Figure 3.3: A Full Adder 

the arithmetic domain. The two domains are called B*, for boolean values (true 
and false ) plus vectors of booleans, and W, for the whole numbers: 

D con = {true, false, [6 0 ,..., 6„]} 

Dab* — W(Whole Numbers). 

Our abstraction function is 

ABS{true ) = 1 
ABS (false) = 0 

• • •, &„]) = £ 0 <,<n 2 i ABS(bi) 

The Adder Cell’s concrete behavior is 

i?£*(Adder Cell) = A a b c . [sum(a, b, c), carry(a, b, c)]. 

The Adder Cell only accepts Booleans, it does not accept vectors. This fact is 
expressed by the input promise 

Boolean^!, i 2 , t 3 ). 

The Adder Cell’s behavior in the arithmetic domain is intended to be 

IBw(AdderCell) = Aabc. a + b + c. 

The Adder Cell’s specification is therefore 


ABS((A a b c . [sum(a, b, c), carry(a, b, c)])(si,s s ,» 3 )) 
= (Aabc.a + b + c)(AB5(t 1 ) > ABS{i 2 ),ABS(i s )) 
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and the verification condition for verifying the Adder Cell is 

V\eB*{Boolean(ii, t 2 ,*3) =► 

ABS((A a b c . [sum(a, b, c), carry(a, b, c)])(*!, *,,*,)) 

= (Aabc.a + b + c) (AB Sfa), ABS (**), AB5(t s ))} 

Using beta-reduction, the above equation can be simplified to 

VieB*{Boolean(i 1,12,13) => 

ABS(sum(ii,i 2 ,i 3 )) + 2ABS(carry(i 1 ,i 2 ,i 3 )) 

= ABS(t'i) + ABS(i 2 ) + ABS (t 3 )} 

This equation can be shown to hold by exhaustively enumerating all combina¬ 
tions of the inputs, thereby verifying the design of the adder cell. 

An example of hierarchical verification in the arithmetic domain appears in 
Chapter 10. That example verifies a multi-bit adder built from Adder Cells. 


3.3 Digital Verification 

Digital verification verifies that the signal behavior of a circuit correctly implements 
the intended digital behavior of the circuit. S, the signal domain, and T, the 
tristate domain, are the two levels of behavioral description of digital verification. 
As mentioned previously, signals are characterized as mapping time into a voltage 
and a strength, S : time -*■ (voltage x strength). The tristate domain is {false, 
true, float}. We have ABS s _ T : S -* T. In this section we assume some 
magic function which yields B s (Design) for any Design. Later chapters discuss 
how Bs (Design) is generated. 

This section uses as examples only combinational circuits (i.e., combinations of 
gates) with electrically isolated inputs. This simplifies the abstraction function and 
allows us to concentrate on the process and major ideas of digital verification. Later 
chapters handle circuits with both state and non-electrically isolated inputs. Signal 

strength is also ignored here as it is irrelevant for the verification of combinational 
circuits. 

The abstraction function we will use in the example is 

ABS = A s . VTB (voltage(s(tf))) 

VTB = A v . v > 3.5 —* true, 
v < 1.5 —► false, 

1 . 
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Figure 3.4: A Minimum Sized Inverter. To ensure that the output of this device 
is valid we must guarantee the input does not suffer a threshold drop. This device 
has one input signal and one output signal. 


ABS accepts a signal S and turns its final voltage into a boolean value using the 
rule that voltages above 3.5 volts give true, voltages less than 1.5 volts give false, 
and other voltages give _L. 

. Stowage™ is given the schematic Design, a specification of Design’s in¬ 
tended tristate behavior IB T (Design), and the logical constraints on it Design. We 

verificatimTis /Br(Z> "** n) = Resign). The verification condiction for digital 

Vi6S ^> P ^ ^ ABS (^(- Dfi5, ^ n )(*)) = /£r(Z?est<7n)(ABS(i))} 


whe ™ P ~ Ini>Ut Coi ! straints u Output Constraints U Logical Constraints. 

Ihe input constraints, which guarantee that inputs are valid, are assumed. The 
output constraints, which guarantee outputs are valid, are automatically gener- 
a e . n y one type of constraint, the threshold constraint, is needed for verifying 
combinational circuits with isolated inputs. The logical constraints are given. 


Example: A Minimally Sized Inverter 

Consider a minimally sized inverter (Figure 3.4). We wish to prove that this device 

computes the boolean NOT function. The inverter takes one input signal and yields 
one output signal. 3 

. T ^r C f d “ re , WhiCh * enerat “ Bs(Design) from Design uses the knowledge 
that ABS only looks at the final value of a signal. The procedure yields 

(Inverter) = 

A in . 
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A t . 

t = t f ~* 

(voltage(m(f)) = 5 -► 1, 

3.5 < voltage(m(t)) < 5 -* 1.66, 

1.5 < voltage(m(t)j < 3.5 -► X, 
0 < voltage(m(t)) < 1.5 -+ 5), 


as the signal behavior of the inverter. This is read as follows. The Inverter takes a 
signal m and returns a signal, call it out. For any time not equal to t f , out returns 
X, meaning an unknown voltage. When time is t f , out returns a voltage based 
upon the circuit model (c/. Chapter 2) and the input voltage. No more detail than 
this is necessary to verify the inverter. 

Inverter s intended boolean behavior is 


IB T (Inverter ) = A a. NOT(a). 

Finally we have the constraint that Input is valid. The constraint guarantees that 

nput s final voltage is either above 3.5 volts or below 1.5 volts. The constraint is 
writicn as 

VV(voltage(m(t / ))) 
where VV stands for Valid Voltage. 

Inverter ,heSe f ° rmuIaS are wra PP ed together to create the verification condition for 


V,€s{VV(voltage(t(t/))) =► 

ABS((A in . 

A t . 

t = f-+ 

(voltage(m(f)) = 5 -»• 1, 

3.5 < voltage(m(f)) < 5 -► 1.66, 

1.5 < voltage(m(t)) < 3.5 -♦ X , 
0 < voltage(m(<)) < 1.5 -► 5), 

Y 

( 0 ) 


= (A a . N0T(a))(ABS(t))} 

This equation can be simplified by using beta-substitution and distribution of func¬ 
tions across the arms of the conditional. The result is 

V.eslVVfvoltagef*^))) => 
voltage(t(fy)) = 5 -b false, 
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3.5 < voltage(*(t/)) < 5 _L, 

1.5 < voltage(i(f/j) < 3.5 -*■ _L, 

0 < voltage(t(f/)) < 1.5 -► true 
= MOT(ABS(*j) } 

The input constraint is used to eliminate the third clause. 6 It guarantees that 

the predicate of the third clause will always be false. Throwing out the third clause 
yields 

' 7 '.6s{V’V'(voltage(t(t / ))) =>• 
voltage(i(fy)) = 5 -► false, 

3.5 < voltage(*(«/)) < 4.5 -► _L, 

0 < voltage(t(f / )) < 1.5 -► true 
= N0T(ABS(t))}. 

The second clause shows an error condition which arises when the final value of 
the input signal is between 3.5 and 5 volts. This condition is indicative of a threshold 
drop The error condition is prevented by generating the constraint that input 
cannot suffer a threshold drop. The constraint is written no-drop(voltage(»(t,))). 
This constraint subsumes ^(voltageflf,))). Posting this constraint yields 

V,es{no-drop(voltage(i(t / ))) => 
voltage(*(f/)j = 5 -► false, 

0 < voltage(t(fy)) < 1.5 true 
= N0T(ABS(*j) } 

Because voltage(.(t,)) = 5 implies ABS(i) and it is the only clause to do so, 

nT? With the latter - Similarly 0 < '' 0 ltage(.(t,)) < 1.5 implies 
NuqABS>(t]J and it, too, is so replaced. These substitutions yield 

V,es{no-drop(voltage(i(f/))) =*► 

ABS(t) - false, 

MOT(ABS(0) - true 
= N0T(ABS(*)) } 

Finally, the upper conditional is recognized as an idiom for NOT and rewritten to 

v i€s{no-drop(voltage(t(t/))) => 

N0T(ABS (*)) 

= NOT(ABS(0) } 


which is true. 


6 [ t n th< constr f| nt “ used to Prevent the third clause from even being generated. 

placT * XP am h ° W 40 ge * nd ° f somethin 8 than to explain why it's not created in the first 
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3.4 Summary 

There are many levels of description for the behavior of circuits. Multilevel verifi- 

cat,on is the succeMful comparison of the same behavior at two different levels of 

description. The abstraction function was the key to relating the two behavioral 
descriptions. 

The verification condition for multilevel verification made explicit many informal 
notions presented m the introduction of this dissertation. These include the relation¬ 
ship between different behavioral descriptions, the relationship between structure, 
function, and context, intentional analysis, the role of constraints, and a method 
tor automatically generating constraints. 

An idealized scenario of how Silica Pithecus verifies a combinational circuit 

was presented. This scenario stressed the abstraction of signals and the automatic 
generation of constraints. 



Chapter 4 

State and Time 


Circuits with state are more complex than combinational circuits. Unlike combina¬ 
tional circuits whose outputs can be predicted solely from the final values of their 
input signals, the outputs of circuits with state depends on their input signals’ en- 
tire waveforms. This chapter motivates and explains the abstraction function used 
by Silica Pithecus which enables Silica Pithecus to verify circuits with state. This 

chapter also develop the input constraints that ensure that all output signals are 
abstractable. 

There are two properties we desire of the abstraction function. First, we want 
the abstraction function to be deterministic . That is, it should guarantee that the 
same inputs (after abstraction) yield the same outputs (again, after abstraction). 

Second, we want to be able to symbolically predict, for all valid states and in¬ 
puts of a circuit, the final state of the circuit. The abstraction function found will 
therefore require that nodes storing state are not corrupted. 1 State and corruption 
are technical terms. State is stored charge that affects the outputs of a circuit. 
Corruption is not so easily defined, although it does correspond to the usual in¬ 
tuitive idea (Corruption is defined below.) There are pathological circuits that 
are designed to corrupt state. Such circuits cannot be verified by Silica Pithecus. 
Fortunately, such circuits are rare. 

Just as the abstraction function given in the previous chapter required threshold 
constraints to ensure outputs were valid, the abstraction function we are looking 
for will require timing constraints to ensure outputs are valid. There are two types 
of timing constraints, stable-after constraints and falls-first constraints. A 
stable-after constraint requires a given signal to be stable after some other signal 
is asserted. A falls-first constraint requires a given signal to fall before some 
other signal changes. These are the only constraints needed to ensure stored charge 


^ he j gen<ra1, and COIT ? Ct ’ 8tatemeilt “ that net* which store state are not corrupted. A node is 
the degenerate case of a net with only one node. We will soon talk in terms of both nets and 
nodes storing charge. 
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Figure 4.1: A NAND Gate. When the upper transistor “stores” a 0 the charged 
stored on the lower transistor can be safely corrupted (».«., C2, can glitch). 


is not corrupted. A control signal is a signal that must remain asserted once it is 
asserted. That is, control(N,) is shorthand for stable-after(N„ N,). 

Silica Pithecus treats state bits as both inputs and outputs of a circuit. The 
abstraction procedure is applied not only to the output signals of a circuit, but also 
to its state signals as well. 2 The signals of nodes which do not store state, do not 
gate transistors, and which are not outputs of circuits are not abstracted. Such 
nodes, called connection nodes, serve only as vias for information flow. Because 

connection nodes are never abstracted, the charge on them can be, and often is, 
freely corrupted. 

This chapter has nine sections. The first section discusses locating a circuit’s 
state nodes. The second section defines corruption. The third section develops the 
i ea of deterministic abstraction functions and shows why the abstraction function 
of the previous chapter is nondeterministic. The fourth section gives the abstraction 
function used by Silica Pithecus. The fifth section presents the representation which 
makes invalid signals apparent. It also shows how constraints ensuring signals are 
vahd are issued. The following sections expand on the fifth section in different 
ways. The sixth section discusses some implementation issues. The seventh section 
presents a fairly complicated example. The eight section generalizes the methods 
to handle circuits containing transistors with different (positive) thresholds. The 
chapter ends with a summary. 


4.1 Finding State in a Circuit 

A node storing charge is a state node if its stored charge can affect a circuit’s output 
behavior. State nodes appear in memory cells, shift registers, and latches. 


3 A state signal is the signal at a node storing state. 
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Figure 4.2: A 4-way Selector. The charge stored on the internal nodes is often 
corrupted during settling. The internal nodes are called connection nodes. 


It is difficult to accurately assess which stored charge represents state. Data 
dependencies allow what would otherwise appear to be state to be freely corrupted. 
For example, consider an nMOS NAND gate with latched inputs whose upper tran¬ 
sistor is storing” a 0 (Figure 4.1). In this case the stored charge on the lower gate 

Ca ? b !. I C . 0rr ^? t f d ( by C2 ‘ pitching) without affecting the outputs of the NAND 
gate. Silica Pithecus does not consider such data dependencies when locating state. 
If there is any point m time at which a node stores state, then Silica Pithecus con¬ 
siders the node to store state at all times. This approach is overly conservative, but 
no problems have yet been encountered using it. 

State nodes are statically discovered by performing a recursive tree scan of the 
net behavior equations of a circuit. The scan starts from the output nodes of the 
circmt. For each node N in the scan, N’s possible nets are examined. If a net is 
not driven then all its dominant nodes are state nodes. The dominant nodes of a 
net are those whose capacitance overpowers* the capacitance of the other nodes in 
the net. If a net contains an input node then the input node is the only dominant 
node of the net. Except for nets containing inputs nodes, a net can contain an 
arbitrary number of dominant nodes. The scan is repeated for each new dominant 
node found and for each node mentioned in the predicates of N. The scan ends 
when no new state nodes are found. 

Nodes which don’t store state and whose signals don’t appear in the predi¬ 
cates of net behavior expressions (•*.«., don’t gate transistors) are connection nodes. 
Connection nodes can be freely corrupted. For example, consider a 4-way selector 
(Figure 4.2). Assume that the four inputs are driven and that both A»(t.) and 
B t (f.) are not asserted. If, during a computation, A* and B» waver before returning 
to being unasserted, then the internal nodes will be corrupted. This corruption has 
no effect on the output of the selector. 

3 Silica Pithecus defines overpowers as ten times greater. 
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4.2 Corruption 


Let net be some final net. 4 We want to be able to predict the voltage of any node 
in net solely from the initial state of the nodes in net. If net contains driven nodes 
then the prediction can be based solely the driven nodes. If net contains no driven 
nodes, then the final voltages can be precisely predicted from initial voltages if and 
only if, during settling, no nodes in net shared charge with nodes not in net. When 
a final net contains nodes which have shared charge with nodes not in the final net, 

we say that the net has been absolutely corrupted. A later section discusses avoiding 
corruption. 


Example: Latched Inverter Cell 


For example, consider again the Latched Inverter Cell (Figure 2.2). Its S node 
has three possible nets, [S], [S, Out, Vdd], and [S, Out, Vdd, Gnd], all of which 
can be final. When S w< (t,) is either [S, Out, Vdd] or [S, Out, Vdd, Gnd] Thevenin 
equivalents are used to calculate the voltage at S. When S^f,) = [S], then absolute 
corruption may have occurred. Consider the computation sequences of Figure 4.3. 
In the upper figure S«.<(*/) (= [S]) is not corrupted because S has not shared charge 
with any other nodes. (Although it began connected to other nodes, it did not share 
charge with them. Remember, it is assumed that circuits start out at steady state.) 
In the lower figure [S] has been corrupted because it momentarily shares charges 

Wlt ro vjj VDD * Another path ( not shown ) which corrupts [S] is [S, Vdd, Out] 
-► [S, Vdd, Out, Gnd] -► [S]. In this case S shares charge with Gnd before being 
isolated. * 

Absolute corruption is too strict a notion. Instead, a less strict form, simply 
called corruption, is more useful. A final net is corrupted if its dominant nodes have 
shared charge with nodes not in the net. Corruption differs from absolute corruption 
m that the charge sharing of non-dominant nodes is not considered. The voltages of 
nodes m a net whose non-dominant nodes have uncertain charge can be calculated 
with sufficient accuracy for verification. 

Dominant nodes cannot be allowed to share charge with any extra nodes, re¬ 
gardless of their capacitance. They might lose enough charge a little at a time such 
that an accurate prediction of voltages on final nets is impossible. 


‘Review the section on signals in Chapter 2 for the definition of final net. 

s Not all of a net’s possible nets can be final. Steady state logical constraints dictate that although 
certam nets can occur during settling, these nets can’t occur at steady state. 
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igure 4.3: Computation Paths. These are two possible computation paths of the 

r» a * C ^nM. InVe f te f Cell s S node • In the upper path S begins connected to Vdd and 
Out. Then the input to the inverter goes low and then Latch falls isolating S. In 
the lower path S begins isolated. Then Latch goes high (while In is asserted) then 
falls, leaving S isolated. The labels of the edges indicate which signal causes the 
transition and the signal’s direction of change. 



72 


CHAPTER 4. STATE AND TIME 

Latch 

In _ Out — 3 


Experiment 1 


Experiment 2 


In 


Latch 


Strength(S) 


Trial 1 


5 volts 


0 volts -« 


5 volts 
0 volts 

5 volts 
0 volts 


Id 


Tin 


Trial 2 Trial 3 TriaU 

1 1 I 


a 




4 ,f: Non-^twminMtk Abstraction. This figure depict, two different exper- 

. . ii 118 . 1 and 2 trias 3 and 4 )- Ead > experiment show, equivalent inputs 

giving different outputs. “Non-deterministic behavior” refers to this phenomenon. 


4.3 Deterministic and Nondeterministic Abstrac- 
tion Functions 

From a theoretical viewpoint, the major problem of the abstraction function of the 
previous chapter, A s . VTBfvoltage^))), is that it projects a non-deterministic 
T : A beha ™>r 13 non-determimstic when the same inputs can give different out- 
puts Two idealized experiments with the Inverting Latch (Figure 2.2) will make 
this dear. Consider Figure 4.4, which shows four different sets of inputs applied to 
the Latched Inverter Cell, and shows the S. which results from the inputs Both 
experiments show the boolean behavior of this device giving different outputs for 

W S T “ ^ firSt experiment ABS ( In «) and ABS(Latch.) are both 0, 

arc?t BS * b } 13 ^ 1 ° r °- In the second P air of experiments, ABS(In.) is 1 and 
ABS(Latch,) is 0, but again ABS(S,) is either 1 or 0. 

There are two ways to project a deterministic B T . The first is to have the 

abstraction function differentiate between inputs which cause different outputs, 

guarantee the inputs will be different when the outputs are different. The second, 

and more natural method, is to declare certain output signals to be invalid. Silica 

Pithecus takes this approach. Its abstraction function will declare S, in trials 1 and 
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4 to be invalid. As a result, when verifying the circuit, Silica Pithecus constrains 
Latch, from glitching and constrains In. from changing before Latch, falls. These 
constraints prevent the invalid signals from occurring. 

eircuit designers will recognize the first pair of runs as exhibiting what is known 
as a hazard and the second pair of runs as exhibiting a “race.” Hazards occur 
when control signals go through too many transitions during settling. The standard 
example (exhibited m the figure) of a hazard is a control signal which begins at 0 and 
ends at 0, but goes through two transitions (up and down). 6 Because the transitions 
of a control signal affect a circuit as much as the value of a control signal, the extra 
transitions cause the circuit to end up in the wrong state. 

Races occur in MOS technologies when the signal isolating an undriven net and 
the signal changing the value of the net both change during the same computation. 
The order m which the signals change affects the final state of the net. If the net 
is first isolated, its final value will be different than if it is changed before being 
isolated. For example, Latch, of the Latched Inverter Cell must fall before In 
changes in order to isolate [S] before it is changed by In.. When In, and Latch, can 
change on the same computation there is a race condition. 

Hazards and races cause corruption. If hazards are outlawed, and races carefully 
ordered then corruption will not occur and a deterministic B T results. The ordering 
of races is presented below. The signals which Silica Pithecus declares to be invalid 
are precisely those which represent (potentially) corrupted state. 


4.4 The Abstraction Function 

The abstraction function has the desirable properties that it projects a deterministic 
Ut and it places timing constraints on inputs to ensure outputs are valid. 

4.4.1 Valid Signals 

The rules for valid signals are presented below. If all output signals (state signals 
are considered output signals) are valid then no state nodes are corrupted. A signal 


• Its strength does not decrease after its voltage changes. 8 

a I often think control signal* are called such not because they control things, but because they 
themselves must be controlled. * ’ ney 

"ordw races WhiCh ° f tW ° “ * r “ e mMt Ch “ ge fi ”‘ ° rdert th * race - Timing constraints 


Jf ^ rule fOT fr^om from corruption. There are a range 

of rules, from simple to complex, that can be used for avoiding corruption. Simpler rules Je 
easier to check than complex rules, but they give more false negatives than complex conditions 
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• Its final voltage is less than 1.5 volts or more than 3.5 volts. 


The two rules are called the strength rule and voltage rule , respectively. 

Sources of corruption can divided into two classes: Momentary Expansion Cor - 
ruptxon, and Driven Corruption. Momentary Expansion Corruption occurs when a 
net expands and then contracts. Except when the net contains driven nodes both 
before expanding and after contracting, the expansion and contraction shows up as 
an increase in strength followed by a decrease in strength. An example of this type 
of corruption is shown in the lower half of Figure 4.3. We conservatively assume 
that the voltage of signal always changes when its strength increases. 9 The Strength 
Kule prevents momentary expansion corruption. 


e stable-after constraint is used to prevent momentary expansion corrup¬ 
tion. It prevents a net from shrinking after it has expanded. The form of the 
constraint is stable-after(X.,Y # ), which means that after X, is asserted, Y, must 
remain stable. It also implies that Y, must be stable as X. is asserted (».«., as X. 
rises, in nMOS). control(x,) is shorthand for stable-after(x„x,). 

Driven Corruption occurs when the initial strength of a signal is oo and the 
voltage of the signal changes before the strength of the signal becomes finite. For 
example considering the Latched Inverter’s S node again, the sequence [S, Vdd, 
Out, Gnd], [S, Vdd, Out], [S], is an example of Driven Corruption. Driven Corrup¬ 
tion is prevented by the Strength Rule which dictates that once a signal’s voltage 
changes the signal’s strength cannot decrease. 


.i J 1 ? constraint “ ““d to prevent Driven Corruption. It ensures 

that strength falls before voltage changes. faUs-first(X„Y,) means that if X, 
must fall before Y, changes. 


The two constants, falls-first and stable-after, are collectively called 
trnnng constraints. The two constraints collectively outlaw hazards and order races. 
Kac« are ordered such that undriven nets are isolated before they are changed. We 
call the ordering of races prescribed by the Strength Rule the natural ordering. 


W “ .'‘""T " ‘ b * * tal>l “‘ "d* "Web verifies mori.circeiw. I«ur«ud reader, can 
W 0W ”- Sffi “ P “““ “ “ “ »—* ** • 

“ is dtr^^de^c^r^ - *“° w Sflk * Pith ““ - u >-~ 

a b * b r *"*«"« *>“ *»"*»» o' X. a. taking eome finite amonnt of time 

rather than the assertion being instantaneous. If we take “after X, is asserted* to mean ‘after X. 

* nd Y - to i ' , “ bi * whfl * x -» b « to « * b “ ■»-<*■« 
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4.5 Issuing Constraints 

The representation of signal behavior makes error conditions (».«., invalid signals) 
exp licit so that constraints guaranteeing valid signals can be automatically gener¬ 
ated. The representation is based on computation paths and net transition graphs. 
Constraints are generated directly from each state node’s net transition graph. 

Unlike threshold constraints which always apply, timing constraints condition¬ 
ally apply. That is, only under certain conditions must X, fall before Y, or must 
X, be stable after Y, is asserted. Associated with each timing constraint is a pred¬ 
icate on the state of the circuit which controls the application of the constraint. 
Only when the predicate is true must the constraint hold. For example, in the 
scenario of the first chapter had the constraint Latch* => overpowers ([In], ,[S] ). 
The predicate is “Latch*” and the constraint itself is “overpowers([In], JSM.” 5 

The elements of the predicates are boolean signals, rather than boolean values, 
and are meaningless unless unless their time component is quantified. We conser¬ 
vatively state that a predicate is true if there is any moment time when it is true, 
lhat is, for some predicate P, P = 3t[P(t)]. 

This section has two parts. It first discusses computation paths and net transi¬ 
tion graphs. It then gives the algorithms for generating timing constraints. 

4.5.1 Computation Paths and Net Transition Graphs 

Computation paths and net transition graphs are formal tools used by steady state 
behavior validation. A computation path is the list of nets, in order, that a node 
18 of during a computation. Figure 4.3 shows two different computation 

paths for the S node of the Latched Inverter Cell (Figure 2.2). In the upper example 

egins connected to Vdd. Then Latch, falls isolating S. In the lower example S 
begins isolated. Then Latch, goes high (while Input, is high) and then low, isolating 
b again. The labels of the edges indicate which signal causes the transition and its 
direction of change. For transistors that turn on, the label also includes a predicate 
escribing the net that merges with the net undergoing the change. For example, 
the first edge of the lower path indicates not only that Latch, is asserted, but that 
it does so when In, is asserted. Had In, not been asserted, the resulting net would 
not have included Gnd. 

The possible computation paths of a given node are formalized as paths through 
a net transition graph. A node undergoes a net transition when the net it is a 
member of changes due to some transistor changing state. For example, referring 
again to Figure 4.3, the change from net [S] to net [Gnd Vdd Out S] is a net 
transition. The vertices of a net transition graph for node N correspond to the 
possible nets of N , and the edges correspond to net transitions of N. n The vertices 


11 To avoid ambiguity a net consists of nodes and conducting transistors whereas a graph consists of 
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Figure 4.5: The Net Transition Graph of the S node of Latched Inverter Cell. 


are labelled with the predicate selecting the net corresponding to the vertex. The 
e ges are labeled as they are labelled in computation paths. A computation path 
is a traversal through a net transition graph. 

Each vertex in a net transition graph is annotated with the strength of the signal 
it corresponds to. A transition in the net transition graph from a vertex to a less 
strong vertex is called a downward transition , to a higher strength vertex is called an 
upward^transition, and to an equal strength vertex a sideways transition. Finally, 

two vertices A and B are neighbors if there is some path of sideways transitions 
connecting them. 

For example, consider again the Latch Inverter Cell (Figure 2.2). The net be¬ 
havior equation of its S node is 


= A t . Latch»(t) A In»(t) -► [S Vdd Out Gnd], 
Latchj(t) A N0T(In»(t)) -► [S Vdd Outl, 
NOT(Latch*(t)) - [S] 


The net transition graph (Figure 4.5) for the S node of this cell has three vertices 
corresponding to S’s three possible nets. Because each possible net can be trans¬ 
formed by a single transistor state change into one of the other possible nets, there 
are six edges m the graph. There are two downward edges for when Latch falls, and 
two corresponding upward edges, for when Latch rises. The are two sideways edges 
corresponding to In’s two states. 


vertices and edges (also called arcs). 
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Figure 4.6: Examples of the three ways a net can expand then contract. In the first 
diagram an upward transition is followed by a downward transition where both 
transitions are caused by the same transistor. In the second diagram an upward 
transition is followed by a downward transition where the two transitions are due 
to different transistors. In the third diagram an upward transition is followed by 
two sideways transitions, then a downward transition is made. 


4.5.2 Ensuring Strength Never Decreases After Increasing 


stable-after constraints ensure a signal’s strength never decreases after increas¬ 
ing. When a signal’s strength decreases after increasing the signal has undergone 
Momentary Expansion Corruption . 12 Momentary expansion corruption is avoided 
by forbidding downward net transitions to follow upward net transitions. 

The ways a signal’s strength increases and then decreases can be divided into 
three classes (Figure 4.6). The first occurs when a control signal (defined below) is 
asserted then unasserted (this is called a hazard ). The second cause of momentary 
expansion corruption occurs when an upward transition is followed by a downward 
transition where the upward and downward transitions are caused by different sig- 


12 W * p “ n 5“ g b * tween corruption of nett and corruption of tignala. We say N. it corrupted if 
and only if N it a dominant node of a corrupted net. 
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nals. The third cause of momentary expansion corruption occurs when an upward 
transition is followed by some number of sideways transitions then followed by a 
downward transition. 

All sources of momentary expansion corruption are avoided by the following 

reauirempnt * **««#»* 


Rule 1: All signals causing downward transitions from a vertex V 
cannot change after any signal causing an upward transition into V or 
into a neighbor of V is asserted. 

, ““tl.-aft. restraints, which ensure this rule is always met, are generated 

by the following algorithm. The algorithm is explained using the notation “PI A” 
which means The predicate P simplified under the assumption that A is asserted.” 
For example assuming that b is asserted by making it true, (and a b c) lb reduces 
to (and a c), and b|b reduces to true. 

Algorithm Generate stable-after Constraints: 

Inputs: The net transition graph G of node N. 

Outputs: The stable-after constraints which ensure N. does not undergo Mo- 
mentary Expansion Corruption. 

Method: 

For each vertex V in G do 
Let P be the predicate choosing V. 

For each downward outgoing edge D from V do 
Let SD, be the signal causing D. 

For each upward edge U into V or into a neighbor of V do 
Let SU, be the signal causing U. 

Issue the timing constraint 

“P|SU» =► stable-after(SU„ SD,).” ■ 

For example consider again the Latched Inverter Cell (Figure 2.2), and the net 
transition graph of its S node (Figure 4.5). The above algorithm generates the 
following two stable-after constraints on Latch: 

• In* -+ stable-after(Latch„ Latch.) 

• -| In* -h stable-after(Latch„ Latch,). 

These two constraints are collapsed into stable-after(Latch„ Latch,), which is 

then simplified to control (Latch,). A control signal is a signal that, once asserted, 
must remain asserted. ’ 
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Figure 4.7: Voltage Changes. Under pessimistic enough conditions, asserting Cl 
can pull X low. 6 


4.5.3 Ensuring Strength Never Decreases After the Voltage 
Changes 

As mentioned above, Driven Corruption occurs when the initial strength of a signal 
is oo and the voltage of the signal changes before the strength of the signal becomes 
finite.For example, considering the Latched Inverter (Figure 2.2) again, S. under¬ 
goes Driven Corruption when the computation path [S, Vdd, Out, Gndl fS, Vdd 

OutJ -> [S] occurs. In this computation path S, starts out at 0 but goes to 1 before 
being isolated. 

Driven Corruption is avoided by requiring a signal’s strength to decrease before 
the signal s voltage changes. Unfortunately, a completely strict enforcement of this 

1 “ P ° SS1 ^ 1 le to venf y ““y reasonable circuits. A strict interpretation 
f this rule will disallow driven nets to expand before contracting. For example, 

? at<i rout * d J to A t I wo Iatches 4.7). Assume that Cl»(*,) is unasserted 

and C2»(t0 is asserted. Also assume that Cl, and C2, can change during the same 
phase. !fC2, becomes unasserted before Cl, is asserted, no problems arise. If Cl, 

f firSt ’ h °™ ver ’ tbenX ' “a* suffer » large voltage change depending on 
the capacitance of Y and the driving force of the gate. 

Circuits such as this are common. We therefore ignore the effects of purely 
capacitive nodes and declare that voltage changes do not occur between comparable 

r!b*\ ni aa? W ° ^ a / 6 com P arable if and only if they be transposed into each 
other by adding and subtracting undriven nodes from their periphery (Figure 4 8 

shows an example). We now state the rule that is used to prevent Driven Corruption. 

Rule 2: Signals causing downward net transitions from a driven 
vertex V must change before signals which cause sideways transitions 
to incomparable nets change. 

The following algorithm enforces Rule 2 by issuing falls-first constraints. 

Algorithm Generate falls-first Constraints: 
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The predicate U abbreviated fall. (Latch,) to yield the final form of the constraint: 
fallafLatch.) => faU.-first(Latch„ In,). This constraint prevents the voltage 
on S from changing before S is isolated. 

Figure 4.9 restates the restrictions and merges the two algorithms together. 


4.6 Implementation Issues 

There are two notes on the implementation that bear mentioning. First, Silica 
Pithecus does not perform a timing analysis. It therefore cannot determine the 
relative ordering of changes in signals. Second, the designer envisioned data depen- 

T 1 !!, ! COntro1 Slgnals are usually much coarser than the data dependencies 
embedded u constraints. This observation is exploited by trying to prove timing 

h ° W ^ nder r coarser data dependencies than under which they are pred¬ 
icated. This results in faster, simpler proofs. 

Silica Pithecus does not perform a timing analysis; it cannot prove that some 
signal changes before some other signal. Therefore Silica Pithecus cannot verify 
circuits relying on races. Silica Pithecus proves that Y. falls before X. changes 

i*if'* " a ‘ lsfies fal i l3 ' f i rst constraints) by showing that X. is stable when Y. can 
fall. Likewise, Silica Pithecus proves that X, doesn’t change after Y, rises (i e 
satisfies stable-after constraints) by showing that X. is stable when Y. can rise.’ 
The lack of a timing system leads to false negatives. These false negatives can 
be avoided by incorporating a timing system into Silica Pithecus. However, since 
circuits which rely on races are rare, this is not a major drawback. 

The dependencies intended by the designer are simpler than the data dependen- 
^:^r n V“ tS - u A designer often “tend, a restriction on a signal to hold 
^ COndl J! M ’ bu * the timmg constrainta onI y restrict the signal under a few 
specialize*! conditions. For example, where timing constraints require a signal to be 
a control signal only at certain times, a designer often intends the signal to always 
K° Slgna * ' , A . SeC ° 1 nd exam P le is a "W** constraint generation re- 
"abl! during^ ri " g C ° mputation b “‘ *•“ *-«■«« intends 

Silica Pithecus exploits the simpler data dependencies of real designs by attempt- 

° timi “ g Conatraints ^^8 si mpler (more restrictive) data dependencies 

than they are predicated under. This is advantageous because it is easier to sat- 
isfy tumng constraints using simpler data dependencies. For example, when Silica 
Pithecus has to prove that Y. is a control signal on P, it first tries to show that Y. 
ither is stable on P or that Y, is always a control signal. Only if these attempts 
fail does it try to prove Y, is a control signal on P. 

When proving some restriction is true on P Silica Pithecus will sometimes try 
to prove the restnction holds even when P is false. For example, often the only 
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Rule Is All signals causing downward transitions from a vertex V cannot change 

after any signal which causes an upward transition into V or into a neighbor 
of V is asserted. 

Rule 2s Signals causing downward net transitions from a driven vertex V must 

change before signals which cause sideways transitions to incomparable nets 
change. 

Algorithm GENERATE TIMING CONSTRAINTSs 

Inputs: The net transition graph G of node N. 

Method* 5 ThC C ° nStraints which ensure a signals stre ngth does the right thing. 

For each vertex V in G do 
Let P be the predicate choosing V. 

For each downward outgoing edge D from V do 
Let SD, be the signal causing D. 

[Generate stable-after constraints.] 

For each upward edge U into V or into a neighbor of V do 
Let SU, be the signal causing U. 

Issue the constraint 

“P|SU» =► stable-after(SU„SD,).” 

[Generate falls-first constraints.] 

If V corresponds to a driven net then 

For each sideways edge U of out of V into an incomparable vertex 
Let SU, be the signal causing U. 

Issue the constraint 

“P A -| SDj(t/) =► falls-f irst(SD„ SU,).” ■ 


Figure 4.9: The Restrictions on Net Transitions and Their Implementation. 
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Figure 4.10: An OR Gate Implemented in CMOS Domino Logic. Node Internal is 
go^glT* ° n * 1 ‘ Enal>Ie 8068 high ° n A * and B * must be stabIe when Enable 


reliant termofPis that some clock is asserted. If the clock is asserted, then the 
restriction will hold regardless of whether P itself is true. 


4.7 A Complex Example 

As a more complex example consider an OR gate designed with CMOS Domino 

\ ram ^ 1 if lgUrC 4 * 10) - U i8 ^ 33 folIows - 0n one P baa « Precharge is 
eld high and enable, is held low. During this time A, and B, are free to settle. 

On the next phase Precharge, is low while Enable, is high. During this time A, 
and B, are stable. The relationship between signals informally stated above are 
automatically discovered, and stated as timing constraints. 

4 i lufi 61 n ° W u h t ne V ransiti ° n graph of the ^mal node of this device (Figure 
-LJ * ?" aph ha f five vertlces Md twelve transitions. The timing constraints 
generated for this graph appear in Table 4.1. The numbers in this figure correspond 
to the numbered vertices in the OR gate’s net transition graph. 

The timing constraints are summarized and compared against the designer’s 
restrictions in Table 4.2. The only restrictions that match completely are the ones 
requiring Precharge to be a control signal. The other timing constraints depend on 
more factors than the designers restrictions. The designer intends A, and B, to be 
stable when Precharge* is low, they only change when Precharge* is asserted. The 
timing constraints only require A , and B, to be control signals when Precharge* 

13 The graph in the figure is not the real graph, which has 11 vertices and approximately 40 arcs 
r n0d “ 10 ■“ by only on. ».r,„ 
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Figure 4.11: The Net Transition Graph of Internal Node of the CMOS Domino 
Logic Or Gate. This is an abbreviated form of the real net transition graph. In this 
graph vertices with same set of nodes are merged. 

















4.8. GENERALIZING TO MULTIPLE TYPES OF TRANSISTORS 
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1. NOT(Ai) A NOT(Bt) -► control(Precharge,) 

2. A 4 V B t -* control(Precharge,) 

3. A t V B k —*• control(Enable,) 

Enablej -*■ control(A,) and control(B,) 

A» -*• s table - af ter (Enable,, A.) 

B» -+ stable-after(Enable„ B,) 

Enable* -► stable-after(A„Enable,) 

Enable* -+ stable-after(B„ Enable,) 

4. N0T(A») A NOT(Precharge*) -► control(B,) 

NOT(Bj) A NOT(Precharge t ) -*• control(A,) 

Table 4.1: Timing Constraints for the Domino Logic OR Gate. 


is low, rather than to be stable. Also, where the designer intends Enable, to be a 

control signal, the timing constraints only force it to be a control signal when A* or 
dj is nigh. 


4.8 Generalizing to Multiple Types of Transistors 

This section generalizes the ideas to include circuits containing multiple types of 
transistors. The theory readily extends to transistors which conduct when their 
ga es are ofT (at 0 volts) such as p-channel transistors. (Silica Pithecus only 
handles nMOS circuits with only one type of positive threshold transistor.) 

... ® t . h ®° r ^ d ° es n T ot readily ha ndle circuits containing transistors with different 

t In / articuIar ’ ' lt doesn,t correc tly handle multiply connected 
nodes where the redundant transistors have different thresholds. Nodes X and Y 

are multiply connected when there is more than one path of conducting transistors 
miundant^ em ^ tranS1St0rS which make the multiple paths possible are called 

?° r eX ^ apI f’ f? I l sider f a cM0S tran *™**'on gate (Figure 4.12). This device is 
used as a threshold drop free switch [Weste]. When A» is asserted both transistors 
conducting. If X is at Vdd, Y will eventually be pushed to Vdd across the p- 
channel transistor. If X is at Gnd, Y will eventually be pulled down to Gnd across 
n-channel transistor. If both transistors are conducting (which occurs when 
A. changes value) there are two connections between X and Y. If either transistor 
stops conducting, X and Y will still be connected because the other transistor is 
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Generated Constraints Designer Restrictions 

c one rol (P recharge.). 

Same 

Enable* -*• control(A,) 

A* A B* A-iPrecharge* -+ control(A,) 
stable-after(Enable,,A,) 
stable-after(A,,Enable,) 

-'Precharge* -+ stable(A,) 

Enable* —► control (B,) 

A* A B* A-'Precharge* control(B,) 

stable-after(Enable„B.) 

stable-after(Enable„B,) 

->Precharge* -► stable(B,) 

A* v B* —► control (Enable,) 

c ont rol (Enable,) 


Table 4.2: Comparing the Designer Restrictions and the Generated Restrictions. 


X 




-T 

A 1 

S' 1 '* C . M0S Trans J mi33 ‘on Gate. This is an example of a circuit which gives 
rise to mult,ply connected nodes. This circuit occurs frequently in practice. 


still on Therefore, there are three configuration. of the transistor states yielding a 
net containing X and Y. 6 

As an example of circuit where multiply connected nodes cause problems, con- 
1 er e circuit of Figure 4.13. In this figure there are two types of positive threshold 
transistors The transistor gated by B is of one type and the other transistors are of 
the other type. The transistor gated by B has a threshold (called Thresh-B) which 
is lower than threshold of the transistor gated by A (called Thresh-A). Assume that 
all transistors are initially off and that N is at ground. If the circuit undergoes the 
transitions A high, B high, B low, my method will calculate the wrong voltage for 
N, namely VDD - Thresh-A. The correct voltage is VDD - Thresh-B. This bug 
arises because the original rules did not account for different threshold drops. 

The correction is to treat some sideways transitions as if they were upwards 
transitions. This is done by assigning to vertices secondary numbers based on the 
ypes of transistors m them. These secondary numbers can be used to order vertices 
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Figure 4.13: A Circuit Containing Two Types of Positive Threshold Transistors. 
All the transistors are n-channel. The threshold of the transistor gated by A is 

thresh-A and the threshold of the transistor gated by B is thresh-B. Thresh-B 
is smaller than thresh-A. 


just as strength is used to order vertices. Transistors with smaller thresholds would 
have higher secondary numbers associated with them. With this subnumbering 
scheme the original rules of computation paths can still be used. Vertices would 
first be ordered by strength and secondarily by types of transistors. 


4.9 Summary 


Signals are abstracted into digital values by first making sure they are valid, and 

then turning their final values into digital values. A signal N, is valid when 

is not corrupted. v // 

An explicit representation for signal behavior, called net transitions graphs was 
developed. This representation makes invalid signals explicit. It also yielded a fast 
and effective method for automatically generating constraints which guarantee all 
output signals will be valid. 

The method was extended to handle all MOS processes. The extension only 
required a more precise ordering of the possible nets of a circuit. 






Chapter 5 

Non-isolated Inputs 


This chapter confronts non-electrically isolated inputs. The Inverting Latch of 
Chapter 1 is an example of a circuit with a non-electrically isolated input. When 
Latch is asserted, the input node In is connected to node S. This connection af¬ 
fects the input signal applied to In. There are two ramifications of non-electrically 
isolated inputs. The first is ensuring information flows from an input node into a 
circuit, rather than vice versa. The second is augmenting the generation of timing 
constraints to accommodate nets which contain input nodes. 

Another type of constraint, called a flow constraint, is needed to ensure that 
input nodes act as inputs. An input node N of circuit C acts as an input only when 
the signal S applied to N is not materially changed by C. S is materially changed 
by connection to a C when the abstraction of S when it is connected to C and the 
abstraction of S when it is not connected to C differ. When S is materially changed 
y then N is acting as an output node. Input signals are usually materially 
changed by momentary connections to driven nodes and by charge sharing bugs. 

This chapter has two sections. The first section discusses flow constraints. The 
second discusses issuing timing constraints for nets which contain input nodes. 


5.1 Flow Constraints 

Flow constraints dictate that signals must flow into input nodes and out of output 
nodes. A node acts as input of circuit C only when signals flow into C circuit 
through it. Likewise, a node acts as an output of circuit C only when signals flow 
out of C through it. The generation of flow constraints requires access to a circuit’s 
intended digital behavior. The intended digital behavior defines which nodes are 
inputs and which are outputs. 

For example, consider again the Inverting Latch of Chapter 1. Assume that the 
capacitance of its S node is lOOpf. Further assume that its Input node is connected 
to a precharged bus whose capacitance is only 50pf. When the Latch goes high 
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signai flow will be from S to Bus, thereby changing Bus. This change is contrary 

to the designer s intentions of Bus changing S. In this scenario, Input is acting Z 
an output node, not as an input node. * 

siJir v lt°V S COnStrained by the powers constraint. There are two ways a 

greaterthan Y W *”37" V*"? ^ Y: When *’ S Stren * tb « Gently 
greater than Ys strength, 1 or when X and Y have the same logical value. The first 

a°drcuit n r bC ^ Statically without recourse to the “run-time” behavior of 
a circuit. A signal X overpowers a signal Y when V* [overpowers (X,(t), Y,(t))l. 

tion ThHerTt^ be f r maUy motivated by c ^«ing the abstraction func- 
K abstraction function rejects input signals which were materially 

oect, of by f - he f CirC A t0 Whlch they Were input * We wiI1 not develop the formal al 
pects of motivating flow constraints. The interested reader is encouraged to conduct 
this investigation on her own. conauci 

The following notation is used in this chapter. Let Net = [N lt ..., AU be a net 
Net N . represents the signal value computed by Net at node JV,-. 

5.1.1 Input Nodes 

“*V“ “ in P ul "O' 1 ® t0 circuit O when th. signal applied to N by th. 

eaW th v r'T?" ,he Signal * ppU * d *° N ** C - L “ T be the transistor 
™J“ c n0d ' °" the other Iide ° f ‘he transistor from IV. A nods 

NNETil^ ' time lh * on N ' s » id ‘ <* the transistor (called 

NET) overpowers the net on O s side of the transistor (called ONET). Therefore a 

flow constraint for input node N has the form P => overpowersUV NET* ONET ) 

r 0 r p ^ the r dic .r e , whidi causes nnet * b « - « ^I^oneI 

has theform' °n T ' Whe ” constraints are generated NNET always 

becomes a net ^ fl ° W constraints are propagated (ef. Chapter 11) NNET 

For example, consider the Inverting Latch again. Its In’s net behavior equation 


is 


I^net — At 


Latch*(t) -f [In S], 
N0T(Latch*(t)) [In]. 


B«ate‘°of b t e his“ti,e P clsTr^ 1 " 1 '" ° VerP °' Ver ^ W, “ neW U * d ‘ h *"“• 

Latch* => overpowers ([In] /n , [S] 5 ) 

tovertMUtih ‘ h * “T* C0 . Mtraint of * h ‘ four eonetraint, generated for the 
nverting Latch.) In general, an mput node having N clauses in its net behavior 

1 Silica Pithecua defines ‘sufficiently greater* as an order of magnitude greater. 
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expression will generate N - 1 flow constraints. The 
flow constraints for input nodes. 


following algorithm generates 


Algorithm Generate Flow Constraints for an Input Node I: 

Inputs: /’s net behavior NB. 

Outputs: The flow constraints ensuring I acts as an input node 
Method: 


For each clause C of NB do 

Let Net be the consequent of C and P be the predicate of C. 
Let T be the transistor gating I. 

Let O be the node on the other side of T from I. 

Let ONET be the net on O’s side of T. 

Issue the flow constraint “P =>• overpowera([I] / , 0Net o )”. ■ 


5.1.2 Output Nodes 

Node N acts as an output node of circuit C only when information flows out of 
C through N. This is the inverse of an input node. Using the same notation 
“ tor flow constraints on input nodes, flow constraints on output nodes look like 
P =* overpowers(ONET 0 ,NNETjv). 

Output constraints are not explicit. When an output node connects with an 
input node, satisfying the flow constraints of the input node automatically satisfies 
the flow constraints of the output node. When two or more output nodes connect, 
Silica Pithecus checks for conflicts: when two different devices can simultaneously 
drive the same node to different values an error is signalled. 


5.1.3 Buses 

Besides input and output nodes, circuits also use bus nodes. A bus node sometimes 
acts as an input node, and sometimes acts as an output node. The methods above 
do not work for bus nodes because they are not purely either input or output nodes. 
The solution is to examine the intended digital behavior to determine when a bus 
node is to act as an input and when it is to act an output. Flow constraints are 
tnen generated to make buses act appropriately. 


5.2 Timing Constraints 


When a net NET contains an input node special care must be taken to ensure the 
input node doesn t corrupt NET. If the input node changes value before being shed 
from NET then NET may be corrupted. Extra timing constraints (specifically, 
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falls-first constraints) must be generated to avoid this form of corruption. The 
following algorithm is used to generate these constraints. 

Algorithm Generate More falls-first Constraints: 

Inputs: The net transition graph G of node N. 

Outputs: The falls-first constraints which prevent Input Node Corruption of 

IN # . 

Method: 

For each vertex V in G do 
Let P be the predicate choosing V. 

If V contains an input node I then 
For each downward outgoing edge D from V to W do 
Let SD # be the signal causing D. 

If W does not contain I then 

Issue the constraint “P A -SD 6 (t f ) => falls-first(SD„I,).” ■ 



Chapter 6 
Silica Pithecus 


SilicaPHhecus is the implementation of my theory of multilevel verification of MOS 

r/ou- Chapt ' J r disc '? s5 “ th « structure of Silica Pithecus and presents parts 

ot oilica Pithecus undeserving their own chapter. 

The major operations performed by Silica Pithecus depend on whether it is 
performing flat verification or hierarchical verification. The primary operations of 
ilica Pithecus when performing flat verification are constructing a representation 

ma ^ eS inVaUd Signals apparent > and issuin 8 constraints which 
ensure those invalid signals never arise. The primary operation of Silica Pithecus 

when performing hierarchical verification is processing constraints to show they 

u° th f0rm ? Y 6 thC inpUtS to SiIica Pithecus ’ namel y the specifica¬ 
tion of digital behavior and the specification of circuit structure. Digital behavior is 

spe cified as a program written in a programming language supplied by Silica Pithe- 

twrl a T! g , e haS an interpreter, specifications can be debugged by executing 

Nation Z p !L CUSSe ? m ® tail the ■ p6dflcat ioii of'digital systems and the moti- 
tion for Silica Pithecus s method of specifying digital behavior. The specification 

of circuit structure is not presented in this dissertation, but the representation of 
circuit structure is. 

This copter has three sections. The first section discusses the structure of Silica 
Pithecus. The representation of circuits is presented in the second section. The last 
section describes how Silica Pithecus compares digital formulas. 


6.1 The structure of Silica Pithecus 

The structure of Silica Pithecus depends upon the type of verification it is perform¬ 
ing. We first discuss Silica Pithecus’s operation during flat verification, then its 
operation during hierarchical verification. 
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Figure 6.1: Outline of Silica Pithecus When Performing Flat Verification. 



6.1. THE STRUCTURE OF SILICA PITHECUS 


95 


When performing flat verification 
They are: 


Silica Pithecus has five phases (Figure 6.1). 


Generation of net behavior. Net behavior, introduced in Chapter 2, is a rep- 
resentation of a circuit’s dynamic structure. Net behavior makes explicit the 
timing constraints needed to ensure state is not corrupted. A hierarchical 
method is used to generate net behavior. Chapter 8 presents the details of 
generating net behavior. 

Issuance of timing and flow constraints. The algorithms for generating tim¬ 
ing and flow constraints were presented in Chapters 4 and 5. 

Generating and abstracting signal behavior. Silica Pithecus generates signal 
ehavior from net behavior. Signal behavior is then abstracted to the digital 
level. During this phase threshold constraints are generated. 

Although generating signal behavior from net behavior is conceptually sepa¬ 
rate from abstracting digital behavior from signal behavior, the two are dis- 
cussed together. This is an artifact of intentional analysis; signal behavior 
itself is not important. The abstraction of signal behavior is. Therefore, 
much of signal behavior generation is bypassed, 1 which forces us to treat the 

two operations, generation and abstraction, together. Chapter 9 presents this 
part of Silica Pithecus. 


Checking the generated constraints. The generated constraints are processed, 
ejected constraints are returned to the designer as errors. Propagated con¬ 
straints are attached to the circuit being verified. (At any given level of 
structural hierarchy a constraint is either satisfied, violated, or propagated to 
the next higher structural level.) 

Comparing arbitrary digital expressions. The comparison of digital expres- 
'T « » time-consuming operation. The general problem is NP-Complete. 

Uica Pithecus does not try to solve this problem elegantly. Instead, it relies 
on hierarchy to manage the problem. Silica Pithecus’s comparison methods 
are presented m the third section of this chapter. 


The general theory of hierarchical verification is presented in Chapter 10. Chap- 
ter 10 shows the advantages of hierarchical verification, states the requirements on 

a verification system that make it work, and gives some concrete examples in the 
arithmetic domain. 

ure^. 11 Perf ° rming hiera rchical verification Silica Pithecus has four phases (Fig- 


1 Which is good, since generating actual signal behavior is very hard! 
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Constraints Either VERIFIED or NO, HERE’S WHY 


Figure 6.2: Outline of Silica Pithecus When Performing Hierarchical Verification. 
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Name 

STORAGE-GATE 

READ-GATE 

WRITE-GATE 

Bus 

A 

Storage 

Unnamed 


PARTS 

Type Renaming Information 

Transistor Drain = A, Source = Gnd, Gate = Storage 
Transistor Drain = Bus, Source = A, Gate = Read 
Transistor Drain = Bus, Source = Storage, Gate = Write 

. CONNECTIONS 

(Dram READ-GATE) (Source WRITE-GATE) 

(Source READ-GATE) (Drain STORAGE-GATE) 

(Gate STORAGE-GATE) (Drain WRITE-GATE) 

(Source STORAGE-GATE) Gnd 


Table 6.1: Representation of the Three Transistor Ram 


Mapping components’ constraints. The major part of hierarchical verification 
is the mapping of the five different types of constraints. Each type of constraint 
has its own special handler. Chapter 11 discusses constraint mapping and 
constraint checking. * 


Checking the mapped constraint,. Thia the same aa for Sat verification. 

Generating digital behavior. The digital behavior of the whole ia the compoai- 
tion of the components’ digital behaviors. 

Structural comparison. The structural hierarchy of the derived digital behavior 
is compared against the funcational hierarchy of the intended behavior. The 
comparison is described below. 


6.2 The Hierarchical Representation of Circuits 

Circuits are specified hierarchically where the primitive devices are those provided 
by the technology being verified [e.g., DFETs and EFETs in nMOS). My represen- 

idlnt^Uo'D^L^DpEi.^ " tW8 hiCrarChy * ThiS repre8Cntation is 

The primitive circuit element is the transistor. It has three terminals called 
Drain, Source, and Gate. Consider the Three Transistor Ram (Figure 8.2), which 
is composed solely of transistors. The representation of this circuit consists of a 
listing of its parts and the connections between them (Table 6.1). Circuit names 

Ua' Tran { ist ° r RAM ) are writte * “ italics, and instance names 

[e.g., STORAGE-GATE) are hyphenated and capitalized. 

The structural representation of a circuit has two sections. The Connections 
section lists and names the connections between the components. The Parts sec- 
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tion lists the components, their names, and renaming information. The renaming 
information dictates how names of components map to names of the parent circuit 
Renaming information is used heavily. Note that the component’s names ( t.g ., tran¬ 
sistor) are listed, not the components themselves. This is a “pointer” scheme by 
which only one prototype of a circuit exists regardless of how many larger circuits it 
is part of. There are two advantages to this scheme. The first is a saving in storage 
for circuits used many times. The second, and more important, is having to analyze 
a circuit once instead of the number of times it occurs in larger circuits. 


6.3 Comparison 

The type of comparison performed depends on whether flat or hierarchical verifica¬ 
tion is performed. Flat verification requires comparing arbitrary digital expressions 
tor equality. Arbitrary comparison is computationally intensive. Hierarchical ver¬ 
ification requires comparing structurally similar digital expressions. This type of 
comparison is computationally inexpensive. 

Silica Pithecus uses a very simple theorem prover to show two digital expressions 
are equivalent. The only complication is the presence of float's which occur in 
conditional expressions.* When faced with conditional expressions Cl and C2 Silica 
Pithecus shows that they are equivalent assuming that the first predicate of Cl is 
true and assuming that the first predicate is false. This generates two simpler 

subproblems. The second subproblem may involve conditional clauses, in which 
case the strategy is reapplied. 

When hierarchical verification is performed the structural hierarchy of the sche¬ 
matic and the functional hierarchy of the intended behavior must match. Silica 
ithecus determines if the input/output relationships of the functions in the digital 
specification and the wires in the structure correspond (i.e., the procedures and 
components are similarly “wired”). 

For example, consider a sum of products device (Figure 6.3). Let the intended 
behavior of this device be 

(db (Sum-of-products x y z) 

( + (* x y) (♦ (* x z) (* y z )))) 

This device is correct only if devices PLUS1 and PLUS2 were verified to have 
diptal behavior *+”, devices TIMES1, TIMES2, and TIMES3 were verified to have 

behavior , and the are wire according to the dataflow prescribed by the intended 
behavior of the entire device. 


2 Don’t care values would cause similar problems. 












Chapter 7 

Specifying Digital Systems 


As defined in Chapter 3, the digital descriptive level consists of Booleans, float , 
bodean functions and join. All complex digital systems are created from These 
primitives .This chapter addresses how we specify the combination of these primi¬ 
tives to build complex devices. P 

wnrS^Mi f ysten V/ e hard to describe because there is no single notation that 

a cental f r Sa T *' 9 i' ^ C6ll) ’ medium («•*. a 16 bit adder), large (e.g., 
a controller), and very large (e.g., a whole chip) designs. Each level has its own 

particular problems and nuances. Notations that work well for small designs are 
often too cumbersome for large designs and vice versa. The notation used by Silica 
Pithecus errs on the side of easily describing large designs at the expense of not 
concisely describing small designs. 

This chapter has five sections. The first section discusses the issues of describing 
digital behavior common to all designs regardless of size. The second section pro¬ 
poses using programs for specifying digital behavior 1 and covers the advantages and 
isadvantages of doing so. The third section gives a rationalization and overview of 
the appheative programming language used by Silica Pithecus for describing digital 
ystems. The fourth section is a reference manual of this language. The last section 

presents a large example which shows the specification of a reduced instruction set 
computer. 

T VA rge degree ’ there is nothing new in this chapter. Many of the ideas 
presented here are germane to the applicative programming community. Many 
of our arguments for using applicative programming languages in the description 

formf' ntl Yi a PP ear ^ Johnson [Johnson] (though in a much less accessible 
orm). Other researchers, [Sheeran, Johnson], use the same method of specification 

Ut t °j >r f 0p0S l e; the 0lU y difference is usually syntax. Nonetheless, 
r completeness, and for the edification of readers unfamiliar with the applicative 


1 ^ her ? “r*i! r . Ca “ P Which U8 «* Io * ic for »P««fications. 
[Gordon84b], [Mishra/Clarke], and [Mosskowski]. 


Interested readers are referred to 
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approach, we now present a thorough discussion of the subject. 


7.1 Issues in Specifying Digital Behavior 

The major issues in specifying digital behavior are coverage , extent , and reliability. 

Coverage refers to specifying the behavior of a circuit for all its inputs and 
states. A specification that does not completely cover all inputs and states is called 
incomplete or partial. As will be discussed in more detail below, it is hard for 
specifications to exactly cover the intended digital behavior of a circuit: programs 
tend to over specify behavior, and logic tends to under specify behavior. 

Extent refers to the interval of time (measured in events, such as clock ticks, 
not real time) used in the specification. For example, one may wish to specify that 
once asserted signal X, remains high until signal Y, goes low; this specification has 
greater extent than one time unit. 

Reliability measures the amount of faith one has that a specification is correct. 

As a basis for later comparison consider the listing method of specification: be- 
havior, i.e., next state and outputs, is specified by listing for each input and state 
of interest what the intended behavior is. (This method is, of course, infeasible due 
to the exponential number of entries required for even a modest circuit.) Assuming 
the listing was done correctly the coverage would be exact, there would be no spu¬ 
rious or lacking entries. It would have no extent. Its reliability could be checked by 
writing a simulator for the listing and running the listing as if it were a program. 


7.2 Specifying Digital Behavior with Programs 

Instead of listing all the entries one can write a program in a suitable language 
to compute the intended behavior. I define a “suitable language" as being small 
with well defined semantics. This section gives the advantages and disadvantages 
of specifying digital behavior with programs. 


7.2.1 Advantages of Using Programs 

Programs Can be Debugged and Verified 

Because a program can be executed and debugged, it can be very reliable. In com¬ 
parison to text editors and spreadsheets, the programs describing the digitial be¬ 
havior of even million transistor chips are rather small and extremely heavy testing 
of the program can occur. It is also possible to verify programs. Indeed, proving the 
functional correctness of digital designs is essentially the same problem as proving 
programs correct. 
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Programs Allow Hierarchical Specifications 


An important property of programs is that they can be composed to make larger pro- 

grams. When functional programming languages are used functional composition 

alone suffices for composing programs. Programs therefore allow for hierarchical 

and modular specifications. The specification’s hierarchy can be exploited to great 

6 . ve " ficat,on lf lt matches the structural hierarchy of the design being 

verified (this is discussed in Chapter 6). 


7.2.2 Disadvantages of Using Programs 

Programs are Poor at Specifying Asynchronous Systems 

Programs can be used to describe asynchronous systems. For example, CSP [ref¬ 
erence] and ADA tasks [Reference] can be used to models asynchrnous systems. 
Nonetheless, programs fail for specifying the intended behaviors of systems. The 
problem is that what we often wish to prove some property of the behavior holds. 
That after some time, the system will acknowledge a request, or that some ar- 

r*‘ er , Pr ,°^ i er i y , arbl ‘ ates * Such Properties are best specified by temporal logics 
[Mishra/Clarke] rather than by programs. 


Programs Have Coverage Problems When Inputs are Not Restricted 

Programs are prone to have coverage problems, they often specify behavior that 
should be left UMpectfied (».«., a value is specified where there should be a don’t 
core). This bug is very hard to catch unless it is specifically tested for: normal 
tests of program will probably never exercise the code that is “buggy." Indeed the 
program may have all the functionality and work correctly for all correct inputs. 
But the circuit to be verified may assign different values to the don’t cares. When 

verified against the program it would not pass because it did not do what the 
program did. 

A concrete example will make this clear. Consider a memory circuit for storing 
four bits. There is one bus, four read lines, and four write lines. The designer 
may intend for only one bit to be writeable at a time and design the circuit that 
way. That is, the circuit will write invalid values if more than one write line is 
asserted. A program to specify the memory could be written and “debugged” with 
only one write line asserted at a time without the designer noticing the program 
allows simultaneous writes to more than one bit. Even though the circuit may be 
correct and the specification “debugged,” the circuit cannot be verified against the 

program since the circuit does not allow more than one bit to be written whereas 
the program does. 

The real bug is that the verifier does not know the constraints on the input 
signals. If they are known, a verifier would not attempt to verify behaviors arising 
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fr°m disavowed input configurations {t.g., more than one write line asserted at a 
time). Silica Pithecus, which uses programs as specifications, requires constraints on 
inputs to be explicitly declared. These constraints are used during the comparison 
of the abstracted and specified behaviors. 


7.3 Rationale for Silica Pithecus’s Specification 
Language 

The specification language should have several attributes: 

• It should be a programming language with an interpreter. 

• It should support modular specifications. 

• It should have simple and precise semantics. 

• It should be able to express parallelism. 

satiJfyingThem^ diSCUS8eS theSe g0als and 8ummar izes the language resulting from 


7.3.1 The Goals of the Language 

It should be a programming language with an interpreter. 

One should be able to debug the specifications by running them. If the specifications 
are not correct then the design will not be. 


It should support modular specifications. 


Modularity is the mechanism used to contain complexity. Complex systems are 
uilt by composing together less complex systems. A specification language must 
support modularity by allowing specifications to be composed to make complex 
specifications. For example, a specification for a control unit and a specification for 
an ALU should be composable using functional composition. If either specification 
must be changed m order for them to be composed, then the language does not 
support modular specifications. Under this restriction, languages such as Pascal 

could not be used as a specification language because of potential clashes between 
names of variables. 


This goal constrains the evaluation mechanism for the language. Consider again 
composing a controller and an ALU together. If they simultaneously transmit 
data to each other then they cannot be emulated by standard applicative order- 
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that would require evaluating one before the other preventing simultaneous com- 

mumcation Some form of lazy evaluation must be used to model simultaneous 
communication. 


It should have simple and precise semantics. 

Simple and precise semantics is required by the need to know what a program in 
the language means. If that is not easily known then comparing programs the 
abstracted and specified digital behaviors of a circuit) is meaningless. 


It should be able to express parallelism. 

The ability to express parallelism is mandatory because a digital circuit may be 
computing many things simultaneously. 

7.3.2 Overview of the Resulting Language 

The language that resulted from these goals is a functional language whose data 
types include boo eans, floats (whose sole member is float), veetors (ordered col- 
lections of objects) streams (infinite lists of objects), and both simple and higher 

a^ments 64 ^ 63 * Certam bindin * forms automatically delay the evaluation of their 

A H of the goals are met by virtue of the language being functional and having 
first class function objects. A functional language does not specify the order of 
evaluation of its terms. It therefore supports expressing parallism. Functional 

ngauges generally have simple and precise semantics, this one has so few data 
types it s simpler than most. 

The only problem with this approach is specifying the behavior of circuits con¬ 
taining state: side effected variables cannot be used to model changing state. There 
are two solutions to this problem. The first treats circuits as functions from inputs 
and states to outputs and new states. This solution is undesirable because of the no- 
a ions 1 overhead of explicitly recapturing and transmitting state in every function 

° r TZ™ °u jeCt With State * The treats circuits containing 

state as functions taking the initial state of the circuit and returning a function 

that takes a stream of the circuit’s inputs over time and returns a stream of the 

circuit s outputs over time. Using this convention, purely combinational circuits are 

specified as functions mapping streams of input to streams of output. We will use 
the second solution. 

Although there are primitive, in the language for creating lasy conatruct. tie lambdnl th« 

p,io “ 01 "“ K .t 
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By using streams, functional composition can be employed to compose specifica- 
tions of objects containing state. For example, assume that A, B, and C are single 
bit shift agisters already initialized with state, and that they take two arguments, 
* nd Shl “' Both arguments are streams of l’s and 0’s. When a component 
, 7 \ the corres Ponding components of Input is shifted in and the current 
state shifted out; otherwise the shifter maintains its current state. A three bit shift 

register (i.e., it takes three shift instructions for the input to reach the output) can 
be specified as ' 

(lambda (input shift) (A (B (C input shift) shift) shift)). 

7,4 The Digital Specification Language 

This section is a detailed description of the language used by Silica Pithecus. It 
is heavily modelled after Scheme [Abelson]. 3 It differs in that it lacks certain data 
types and features (no catch/throw or quoting mechanism), and it adds destructur- 
mg binding and new function defining forms. It uses lexical scoping and a mixture 
o lazy and applicative evaluation. We do not present a complete description of the 
language. Only a listing of the data types, the functions operating on those types, 

!f d f pectal factions of the language are presented. Readers not interested, in 
the details can safely skim this section and the next section. 


7.4.1 Data Types 

There are five data types: Booleans, Floats, Vectors, Streams, and Procedures. 
Booleans 

There are only two boolean values TVue and False. They are denoted 1 and 0, 
respectively. The standard boolean functions and, or, and not are primitively 
provided. And and or take an unlimited number of arguments. 


Floats 


There is only one floating value, float. It is bound to the identifier float. The 
only function in the language which accepts float is join. Join takes an arbitrary 
number of arguments. Each argument must be either float, true, or false. If all the 
arguments are float the result is float, if all the non float values are true (false) the 
result is true (false). Float is used to model tri-state busses. 


3 Modulo syntax, my specification method for circuits with states is 
of objects with states in Section 3.4.4 of [Abelson). 

4 This term corresponds to what others have called special forms. 


very simiiiar to the treatment 
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Vectors 

Vectors are a data aggregating mechanism. They act like Lisp’s conses. The prim- 
itive vector, which has no elements, but is bound to the identifier ‘empty*. A 
vector of length N is created using the procedure vector-cons which accepts an 
object of any type and a vector of length N- 1, and returns a vector of length 

• If * is (vector-cons a b) then (first z) is a and (rest z) is b. The function 
nth-vector accepts a vector and an integer. It returns the nth element of the vector 
w ere the counting is zero-based. The function new- vector accepts a vector, an 
integer, and an object. It creates a new vector whose elements match the original 
except for the nth one, which is the object. 8 The function vector takes an arbi¬ 
trary number of arguments and returns a vector containing the arguments. That is 
(vector abed) is the same as (vector-cons a (vector-cons b (vector-cons 
c (vector-cons d ‘empty*)))). Vector can be abbreviated v. 

#<n> v<m> denotes a function call that returns a vector whose contents, when 
interpreted as binary representation of a number, is m. <n>, which is optional and 
defaults to 8, is the length of the vector the function creates. For example, typing 
#3v4 is the same as typing (vector 0 0 l). 8 

The function = when applied to vectors returns TRUE if the vectors have the 

same length and if the corresponding elements of the vectors have the same boolean 
values. 


Streams 

A stream is a mechanism for representing “infinite vectors." A stream is constructed 
with stream-cons which accepts two arguments. If z is (stream-cons a b) then 
(now z) is a and (future z) is b. Stream-cons is like vector-cons, however, the 
second argument, rather than being evaluated, is delayed. When future is called 
to retrieve the second argument it is forced to yield a value. By this mechanism 
delayed expressions can make use of variables which are defined after stream-cons 
is called. Stream-cons can be abbreviated sc. 

The function stream-map is used to map a function across a stream. For 
example, let x be a stream of boolean values, (stream-map (lambda (y) (not 
y)) x) returns a stream whose values are the logical negations of x’s values. 

Procedures 

Procedures are first class objects created by lambda. For example, 

(lambda (x y z) 


The implementation need not copy the whole vector aa long as it acts like it does. 
By my conventions the first bit in a vector is the low order bit. 
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(and x (or y z))) 


denotes the function that accepts three arguments and returns the logical-and of 
its first argument with the logical-or the other two arguments. 


Notes on Types 

There are no functions for determining the type of an object. 


7.4.2 Special Functions 

A special function is a function not all of whose arguments are evaluated before 
invoking the function. Two special functions, cons-stream and lambda, have 
already been introduced. There are four types of special functions: special functions 
for controlling the evaluation process, special functions for creating procedures, 
special functions for binding variables, and special functions for naming “top-level" 

The f ° Ur typCS ar * exemplified b y the special forms cond, lambda, let, 
and define, respectively. 


Evaluation of Control Special Functions 

There are three special functions for controlling evaluation: cond, if, and select. 

^^i fW(l<Pr6diCate> <COn8equent > < else >)- First if evaluates its 
predicate If the predicate returns True then if evaluates its consequent. Otherwise 
if evaluates its else clause. 

Cond is a generalization of if. Its syntax is (cond (<pl> <cl>) (<p2> 

<c 2>) . (<pn> <cn>)). It evaluates the p’s in turn. When one returns True 

cond evaluates its associated consequent. If any predicate returns a non-boolean 
value or no predicate returns True an error is signaled. 

The syntax of select is 


(select <selector> 
(<cl> <expl>) 
(<c2> <exp2>) 


(<cn> <expn>)) 

This is the same as writing 

(cond ((■ <selector> <cl>) <expl>) 
((* <selector> <c2>) <exp2>) 

• • • 

((* <selector> <cn>) <expn>)). 
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Procedure Creating Special Functions 

The only special function for creating procedures is lambda. Its syntax is 
(lambda (<argl>.<argn>) <exp>) 

This create a procedure of n arguments whose body is <exp>. AH variables are 
lexically scoped. 


Variable Binding Special Functions 

There are two special functions for binding forms: let and rlet. The syntax of let 
is 

(let ((<namel> <expl>) 

(<name2> <exp2>) 


(<namen> <expn>)) 

<body>). 

Let evaluates all the exps and then binds them to the names and then evaluates 
Cbody^. Names are either a sequence of characters, as in X, Y, and this-is-a- 
yanable-name or a list of character sequences enclosed in parenthesis such as (A 
ls-is-name C). In the latter case, the associated expression must return a vector 
e same length as the list. Each name in the list is bound to the corresponding 
e ement of the vector. This is called destructuring binding. Destructuring binding is 

used to work around the restriction that procedures only return one value. Examples 
are provided below. p 

Rlet stands for Recursive Let. It is like let except that the expressions of the 
rlet can refer to the variables being bound by the rlet and the evaluation of the ex¬ 
pressions are delayed until they are used. This allows simultaneous communication 
between components of a specification. 7 

For example, assume that Datapath and Controller are procedures repre¬ 
senting their namesakes. Assume further that each takes two inputs, one from 
the outside world and one from the other device, and that they each produce two 
outputs. They would be connected together as follows: 

(rlet (((controller-to-datapath-wire controller-output) 

(controller controllers-input datapath-to-controller-wire)) 

((datapath-to-controller-wire datapath-output) 

(datapath datapath-input controller-to-datapath-wire)) 

(vector controlle r-output datapath-output))) 

P ° OTly With binding. Pathological circuits 

can be specified whose specifying programs won’t run due to definitional loops. To get around 
this problem, the language must really be completely call-by-need. 
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The output of this expression is a vector containing the outputs of the controller and 
datapath which are destined for the outside world. This example uses destructuring 
binding to get at the two outputs of each subdevice (which each return a vector of 
their two output). A more concrete and fleshed out example is presented below. 


Special Functions for Naming Objects 

Define is used for naming objects at “top-level.” The syntax is (define <name> 
<exp>). For example, (define x 3) associates X with the value 3. Similarly 

(define foo (lambda (x y) (+ x x y y))) associates the procedure created by 
lambda with the name foo. 

There are many syntactic sugarings for naming functions. These syntactic sug- 
arings are motivated by the desire to make functions which operate on streams easy 
to write. 

Df (for Define Function) creates a procedure and associates the procedure with 
a variable. The syntax is 

(df (<name> <var-liat>) <body>). 

This is the same as 

(define <name> 

(lambda (<var-list>) 

<body>)). 

Db (for Define Behavior) is used for specifying the behavior of circuits without 
state. It lets one write a function apparently over scalars (*.«., non streams) but 
which operates over streams. For example, whereas the function defined by 

(df (xor a b) 

(and (or a b) (not (and a b)))) 
takes scalars, 

(db (Xor a b) 

(and (or a b) (not (and a b)))) 

defines a function taking and returning streams. Assuming only one argument (db 
(<name> <arg>) <body>) is the same as 

(define <name> 

(lambda (<arg>) 

(stream-map (lambda (<arg>) <body>) <arg>))) 
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The equivalences for functions having more than one argument are extrapolated 
from this one. I use the typographic convention of capitalizing names of functions 

streams)***’ *° StreimS ( ° r which “ ap v<ctora of atr “ ma “> Tec ' ora ° l 

r.iJ!ih be w Vi0 7 f Cir ? itS With 3tate U us * n 8 » syntactic variant of df. 

Like db, it transforms functions taking scalars into functions taking streams. For 

example, consider a shift register which has one bit of state. It continuously reads 
a value and outputs the previous value read. It is specified 

(df ((SHIFTER state) input) 

(stream-cons state (shifter input))). 

This binds shifter to a function taking an initial value and returning a function 
that maps a stream mto a stream. Using plain df this would be specified as 

(df (SHIFTER state) 

(lambda (input) 

(stream-cons 

state 

((shifter (now input)) (future input))))). 

This is a simple example. For a more detailed circuit, such as a register with 
man y inputs, the overhead of continually writing, for example, (now inputl) and 
(future input 2), is very large. I use the typographic convention of writing names of 
functions which take state information and then return a function mapping streams 
to streams (or vectors of streams to vectors of streams) in uppercase. 

Assuming one argument, 

(df ((<name> <state>) <input>) 

<body>) 

is the same as 

(define <name> 

(lambda (<state>) 

(lambda (<input>) 

(map-function-stream 

(lambda (<input>) <body>) 
input)))) 

where map-function-stream is 

(df (map-function-stream function-making-a-stream input-stream) 

(let ((stream 

(function-making-a-stream (now input-stream)))) 
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(stream-cons 
(now stream) 

(map-function-stream 

((future stream) (future input-stream)))))) 


7.5 Examples 

thC digita ! behavior of a Fanatically Reduced Instruction Set Computer 
RISC). A picture of the machine and its architecture appears in Figure 7.1. The 
computer has the same interface and instructions as Gordon’s example computer 
[GordonSS , but is implemented as a RISC machine every instruction executes 
m one cycle) rather than as a microcoded machine. I also specify its behavior 
in much more detail. For example, Gordon treats the ALU and memory of his 
computer as primitive, whereas I fully specify the them. The difference in detail 
is due to his concern for verifying the functional behavior of the computer (i.e. 

prove its microcode is correct), whereas I wish to verify the digital behavior of the 
computer. 

. . T ° th ''“* r *!* n “ tl “ h “ » I 3 *>« Program Counter (PC), a 1« bit accumu¬ 
lator, a 2 word memory where a word is 16 bits wide, and 8 instructions. The 
instructions are 

HALT: Stop executing the program. 

JMP address: Set PC to address. 

JZR °jj ddreSS: ^ thC contents of the accumulator is zero then the PC is set to 
address. 

ADD address: Increment Accumulator by the contents of address. 

SUB address: Decrement Accumulator by the contents of address. 

LD address: Load Accumulator with the contents of address. 

ST address: Store Accumulator into address. 

NOP: Do nothing. 

8 Thia title is due to Jeff Siskind (Siskind). 

9 Barrow also uses Gordon’s example computer in Verify (Bairow). Everything I say about Gordon’s 

example computer apply to Barrow’s example computer. 
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Figure 7.1: A Fanatically Reduced Instruction Set Computer. This computer has 

8 instructions each of which takes one cycle to execute. Its word size is 16 bits and 
its address space is 13 bits. 
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The computer’s front panel contains a bank of 16 toggle switches, lights dis¬ 
playing the contents of the PC and the Accumulator, an idle light displaying the 
computer’s state, a four position knob, and a button. If the machine is running 
pushing the button causes it to stop running. The knob determines what happens 
when the button is pushed when the machine is idle as follows: 

0 The PC is loaded from the toggle switches. 

1 The Accumulator is loaded from the toggle switches. 

2 The memory location specified by the switches is loaded from the accumulator. 

3 The program starts running from the location in PC. 

I will specify the computer in four steps. Each step illustrates a different aspect 
(and idiom) of specifying digital designs. The first step specifies cells. It emphasizes 
that a device’s inputs and outputs are streams, not single boolean values. The 
second step groups cells together. It highlights the creation of vectors and the 
operations on vectors. The utility of using recursive functions to create arbitrarily 
sized devices is also discussed. The third step specifies the controller and datapath. 
It shows how large complex devices containing many disparate parts are wired 
together. Finally, the entire computer is specified. This is specification is amazingly 
small (as the reader can verify by peeking ahead to the end of this section). 

7.5.1 Small Cells 

I will show the specification of a combinational circuit (an adder cell) and a circuit 
containing state (a register cell). 

The Adder Cell 

A full adder takes three inputs and produces two outputs (Figure 7.2). The speci¬ 
fication of this circuit uses a helper function called xor. 


(df (xor a b) 

(and (or a b) (not (and a b)))) 

(db (Adder-cell a b c) 

(vector (xor a (xor b c)) 

(or (and a b) (and a c) (and b c)))) 


Because db was used to define the adder, its inputs and outputs are streams. 
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Figure 7.2: A Full Adder. This is 
specification of an adder. This is 


a pictorial representation of the digital behavioral 
not the MOS implementation. 
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Figure 7.3: A Renter Cell. Ou ^ it i, fed with data which is either fed back from 
its output or fed from an external source. On * the data is passed to the output 


The Register Cell 

The register cell operates in two phases. On the first phase it is loaded with data. 
This data can either be fed back from its output or be external. On the second 
phase the data is passed from the “input port” to the “output port.” Figure 7.3 
shows the nMOS implementation of this cell. Below is the digital specification of 


(df ((REGISTER-CELL statel state2) feedback refresh write input) 
(stream-cons 

; this is the output. 

(if refresh statel (not state2)) 

;; this the next behavior of the device. 

(REGISTER-CELL (cond (write input) 
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(feedback (not state2))) 
(cond (refresh (not statel)) 

(1 state2))))) 


FRISC’a PC has four input sources: feedback from itself, data from the memory, 
data from the instruction register (this implements jumps), and data from the 
mcrementer. The register cell for the PC is specified as 


(df ((PC-REGISTER-CELL statel state2) 

feedback? refresh froa-ir? ir-input 

from-aeaory? aeaory-input froa-inc? inc-input) 
(streaa-cons 

(if refresh statel (not state2)) 

(PC-REGISTER-CELL (cond (froa-ir? ir-input) 

(froa-aeaory? aeaory-input) 
(froa-inc? inc-input) 
(feedback? (not state2))) 
(cond (refresh (not statel)) 

(1 state2))))) 


7.5.2 


Medium Circuits: Building Vectors of Cells 


to OT tL J Um SC u le exa “ ples an adder which adds tw ° similar length vectors 
ogether, and an arbitrary length register array will be specified. These circuits are 

specified as vectors of the appropriate cells. Because recursive functions are used 
in the specification, creating arbitrarily sized devices is automatic. 


An N bit adder 

vect ° ra be used to represent unsigned integers. Given two equal 
ength vectors (numbers) it produces their “sum.” The zeroth element of a vector 

If tb! °^° rder blt * ThC mpUt Vectora contain breams of booleans and the output 
of the adder is a vector containing streams of booleans. 


(df (+ x y) 

(Adder-internal x y streaa-of-Os)) 


(df (Adder-internal x y carryin) 

(cond ((and (eapty-vector? x) (eapty-vector? y)) 
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♦empty*) 

((or (empty-vector? x) (empty-vector? y) 

(error "ran out of one vector")) 

the following let destructures the adder-cell's output 
(1 (let (((sum carryout) 

(Adder-cell (first x) (first y) carryin))) 
(vector-cons 
sum 

(adder-internal (rest x) (rest y) carryout))))))) 


An N Bit Register 

WOrkS f ° r arbitrary length in P uts - The fimction 
i RE A TI 7 N ; BIT - REGISTER 18 called with two vectors VI and V2 each of 
ength N. It then creates a register N bits long whose state is initialized to the 

contents of Vl and V2. The inputs to the register array are streams (for the control 

lines) and vectors of streams (for the word to be stored). Its output is a vector of 
streams. 


(df (CREATE-N-BIT-REGISTER vl v2) 

(let ((N-bit-register (CREATE-VECTOR-OF-REGISTER-CELLS vl v2))) 
(lambda (feedback refresh write Input) 

(Operate-on-n-bit-register 
N-bit-register feedback refresh write input)))) 

(df (CREATE-VECTOR-OF-REGISTER-CELLS vl v2) 

(if (empty-vector? vl) 

♦empty* 

(vector-cons 

(REGISTER-CELL (first vl) (first v2)) 
(CREATE-VECTOR-OF-REGISTER-CELLS (rest vl) (rest v2))))) 

(df (Operate-on-n-bit-register Reg feedback refresh write Input) 
(cond ((and (empty-vector? Reg) (empty-vector? Input)) 

♦empty*) 

((or (empty-vector? Reg) (empty-vector? Input)) 

(error "ran out of a vector.")) 

(1 (vector-cons 

((first Reg) feedback refresh write (first Input)) 
(Operate-on-n-bit-register 
(rest Reg) feedback refresh write (rest Input)))))) 
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7.5.3 Large Circuits: the Controller and Datapath 

The Controller 

The controller has five inputs. Two of them, the knob, which determines what 
happens when the button is pushed, and the button, come from the front panel 
of the computer. Two, the opcode of the instruction being executed, and a signal 
asserting whether the contents of the accumulator is zero, come from the datapath. 
The last input is fa which is supplied by a fa generator living in the computer. 

The controller has two outputs, a wire going to the idle light and a group of 
control signals going to the datapath. I will first give the constants used by the 
controller and then specify the controller. 


;; these are the control signals 

(define pc<-switches (v 0001000000010)) 

(define acc<-switches (v 001 0000000001)) 

(define aenory<-acc -no-fetch (v 001001010001 0)) 
(define fetch (v 0010101000010)) 

(define nop (v 0010000000010)) 

(define pc<-ir (v 1000000000010)) 

(define pc<-pc+l (v 0100000000010 )) 

(define acc<-acc+aea (v 0100000010000 )) 

(define acc<-acc-aea (v 0100000001000)) 

(define acc<-aeaory (v 0100000000100 )) 

(define aemory<-acc-fetch (v 0100010100010 )) 

(define all-signals-low (v 0000000000000)) 

;; these are the opcodes 

(define halt #3v0) 

(define jap #3vl) 

(define jzro #3v2) 

(define add #3v3) 

(define sub *3v4) 

(define Id *3v6) 

(define st #3v6) 

(define nop #3v7) 

; these are the states 

(define idle #2v0) 

(define fetch #2vl) 

(define execute #2v2) 
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Tlu! computer can either be idling, fetching an instruction, or executing an 
instruction. Even when the computer is idling the controller is busy sampling the 
button on every cycle. If the computer is idle and the knob is in position 3 the 
computer will start running its program. If the computer is running then pressing 
the button will stop it. The select operation is used to decode the state of the 
controller and the opcodes it receives from the data path. 


(dt ((CONTROLLER state) knob button »0? opcode phil) 

(if phil y 

(select state 
(idle 

(if button 

(select knob 

(#2v0 (sc (v pc<-switches 1) (CONTROLLER idle))) 

(#2vl (sc (v acc<-switches 1) (CONTROLLER idle))) 

(#2v2 (sc (v memory<-acc-no-fetch 1) (CONTROLLER idle))) 
(#2v3 (sc (v fetch 0) (CONTROLLER execute)))) 

(sc (v nop 1) (CONTROLLER idle)))) 

(fetch 
(if button 

(sc (v nop 1) (CONTROLLER idle))) .halt 

(sc (v fetch 0) (CONTROLLER execute))) ;run 
(execute 

(select opcode 

(halt (sc (v nop 1) (CONTROLLER idle))) 

(jmp (sc (v pc<-ir 0) (CONTROLLER fetch))) 

(jzro (if »0? 

(sc (v pc<-ir 0) (CONTROLLER fetch)) 

(sc (v pc<-pc+l 0) (CONTROLLER fetch)))) 

(add (sc (v acc<-acc+men 0) (CONTROLLER fetch))) 

(sub (sc (v acc<-acc-mem 0) (CONTROLLER fetch))) 

(Id (sc (v acc<-meaory 0) (CONTROLLER fetch))) 

(st (sc (v memory<-acc-fetch 0) (CONTROLLER fetch)) 

(nop (sc (v nop 0) (CONTROLLER fetch))))))) 

(sc (v all-signals-low (■ state idle)) (CONTROLLER state)))) 


10 The button must be constructed to only give a single pulse on the first 
Otherwise the computer will thrash between the run and idle states. 


cycle it is held down. 
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The Datapath 


The datapath contains 3 registers (PC, ACC, and IR), three arithmetic units (an 

S f b A ^ , n? nd T Crementer)> a boolean tester ( w hich returns True if the 
output of ACC is 0), and a 8K word memory of 16 bit wide words. The functions 

specifying the registers are similar to the function specifying the register array 
presented earlier m this section. The specification of the subtracter, incremented 
and boolean tester are similar to the specification of the adder. Only the memory 
unit is different, but its specification will not be presented here. 

There are four outputs from the datapath. Two of them, the opcode of the 
instruction to be executed, and the zero test of the accumulator, are destined for 
the controller. The other two, the contents of the Program Counter and the Accu¬ 
mulator, are sent to the lights on the front panel. 


(df (DATAPATH ir pc acc men) 

(let ((Instruction-reg (CREATE-INSTRUCTION-REGISTER ir)) 
(Program-counter (CREATE-PC-REGISTER pc)) 

(Accualator (CREATE-ACCUMULATOR-REGISTER acc)) 

(Memory (CREATE-MEMORY mem)) 

(lambda (control-linem phil phi2 switches) 

(let (((pc<-ir pc<-pc+l pc<-pc pc<-sw 
ir<-mem 

mem.mar<-ir mar<-pc 
mem.data<-acc 

acc+ ecc- acc<-mem acc<-acc acc<-sw) 
control-lines)) 

(rlet ((pc-output (Program-counter 

pc<-pc phi2 

pc<-ir (low-13 ir-output) 
pc<-pc+l (ine pc-output) 
pc<-sw (low-13 switches))) 
(ir-output (Instruction-reg 

phl2 ir<-mem memory-output)) 
(acc-output (Accumulator 

acc<-acc phi2 

acc+ (+ acc-output memory-output) 
acc- (- acc-output memory-output) 
acc<-mem memory-output 
acc<-sw switches)) 

(memory-output (Memory 

phil phi2 

mem.mar<-ir (low-13 ir-output) 
mem.mar<-pc output-pc 
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mem.data<-acc acc-output))) 

(vector acc-output 
pc-output 

(Vector«0? acc-output) 

(top-3 ir-output))))))) 


7.5.4 Specifying the Complete Computer 

tW C .Tn te T PUt6r ^ n ° W be Spedfied by hookin « to « ether datapath and 
he controller. The output of the computer is the contents of the accumulator, the 

contents of the program counter, and the signal to the idle light. 


(df (COMPUTER state ir pc acc) 

(let ((The-controller (CONTROLLER state)) 

(The-datapath (DATAPATH ir pc acc))) 

(lambda (switches knob button phil p hi 2) 

(rlet (((control-lines idle-light) 

(The-controller knob button acc*0 opcode phil)) 
((acc-output pc-output acc»0 opcode) 

(The-datapath control-lines phil phi2 switches))) 
(vector acc-output pc-output idle-light))))) 


7.6 Summary 

In this chapter we discussed the specification of digital systems. The broader issues 

wl! w systems 7“ *"* «*n an actual descriptive system 

was proposed. We proposed using an applicative langauge for specifying digital 

an a3ic °" for a ^‘language. We showed how 

an applicative language is a natural way for describing complex devices which are 

comnoirt !l mP !, r ViCeS ’ 14 iS a “ natUral Way ” becuase the dataflow in functional 
composition directly mirrors the connections between physical devices That is 

devrces sp^ifled by procedures are "wired up" by the simply ™ m ™ng fuLtio^ 

delayeTe^Z, “ * ^ Which 3UPP ° rts infinit ' <**«•■ 











Chapter 8 

Generating Net Behavior 


Net behavior, introduced in Chapter 2, was employed in Chapters 4 and 5 to gener¬ 
ate timing constraints. In this chapter we discuss some of the philosophical under¬ 
pinnings of net behavior and show how it is generated. The philosophical under¬ 
pinnings relate net behavior to simulation and compilation. The generation of net 

behavior stresses concrete algorithms and the use of logical constants in eliminating 
non-existent nets. 6 


8.1 Net behavior, simulation, and compilation. 


Simulators do a lot of work. Most of the work is repetitive reanalysis of the same 
nets over and over again. The problem is that a simulator must determine the new 
net partitioning that results from any change in transistor state. When the same 
transitions occur repeatedly ( e.g ., every time * goes high), the simulator must 
repeatedly determine the “new” partitioning. This “new" partitioning is usually 
the same as some previous partitioning. Even when a high-level control strategy 
is used, like Mossim s Unit Delay, in which many transistors change state between 
partitioning, work is continually being replicated. 

An analogy can be made between a circuit simulator and a language interpreter. 
A language has a semantics which is implemented by an interpreter, a circuit has 
a semantics which is implemented by a simulator. Just as an APL interpreter 
interprets APL programs, a simulator interprets circuits. Circuit simulators and 
language interpreters suffer the same problem: every time a language construct is 
interpreted, or transistors change state, a constant amount of the same overhead is 
repeatedly incurred deciding what must be done. 


Compilers are used to solve the problem of repeated overhead by incorporating 
the decision of what to do next within the program text. Sometimes this necessitates 
changing the program text (called a source level transformation ), at other times 
it necessitates representing the program at a level closer to the interpreter (such 
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as translating source code into machine code the interpreter is written in) By 
incorporating the decision of what to do next into the program itself, the decision 
need only be made once at compile time. 

Net behavior only enumerates a node’s possible nets once. Net behavior can be 
considered as a compiled form of a MOS circuit. The determination of the circuit 
partitioning for any given state of the transistors in the circuit is done once at 
analysis (compile) time. A major advantage of this approach is that it is possible to 
analyze each possible net of a circuit fully. Steady-state voltages can be determined 
for each possible net (assuming reasonable assumptions about the initial values of 
nodes are made). The goal of research in simulators is to find new ways of avoiding 
the analysis of a net and still accurately predict the steady-state voltages of the 
nets nodes. For example, this was the major motivation behind Mossim and its 
switch level, order of magnitude, circuit model. Mossim repeatedly rediscovers the 
same nets and can’t spend the time to fully analyze each newly activated net When 
nets are only analyzed once, better models can be used. 


8.2 Generating Net Behavior 


A simple method is used to generate a circuit’s behavior equations. The primitives 
(».«., transistors) have fixed net behavior equations. A nonprimitive circuit’s net 
behavior equations are generated by composing the net behavior equations of the 
circuit s parts. This is standard practice in the field of behavioral analysis [Bobrowl. 
There are several advantages to this approach. 


• It exploits structural hierarchy. A circuit is only analyzed once regardless of 
the number of times it is used. 


• It is an incremental method. The work is spread over time as parts are 

connected instead of being done monolithically. As a result of, Silica Pithecus 
responses quickly. 

• It localizes the use of knowledge of a circuit’s logical structure. Logically 
disallowed nets are pruned quickly, avoiding exponential blowup. Other, non- 
hierarchical methods, such as path tracing, are hard to manage because of the 
nonlocalized (and therefore inefficient) use of logical constraints. 

Net behavior equations are only created for state nodes and nodes gating tran¬ 
sistors. They are not created for connection nodes. For example, consider the 
standard nMOS NAND gate (Figure 8.1). The initial voltage of node X in Fig¬ 
ure 8.1 cannot affect the value of the output node. (Although it does affect the 

iming of the transitions of the output node.) Connection nodes are only partially 
analyzed by Silica Pithecus. 
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F'pire 8.1: An nMOS NAND Gate. The state of internal node X does not contribute 

to hnal state of of the output the gate. X therefore does not store state and is not 
fully analyzed. 


Silica Pithecus uses a different control strategy for generating net behavior than 
the one described here. The one described here is clean and easy to explain. For 
pragmatic reasons, the control strategy employed by Silica Pithecus is more com¬ 
plex. Interested readers can look at the code. 


Behavior generation for a circuit C is done in three steps. The input to behavior 
generation is the behavior equations of C’s parts. The output is the behavior 
equations for C. The three steps are: 


1. Renaming the behaviors of the subcircuits of C which use names local to those 
subcircuits to use names of the circuit C. 

2. Merging nets where subnodes connect. Merging is done for all nodes. 

3. Expanding nets to span the circuit C. Expansion is the most expensive part 
of net behavior generation. It not performed for connection nodes. 


This section has three parts corresponding to the three steps above. As a running 
example I will show how the behavior equations of the Three Transistor Ram (Figure 

8 f 2 i are 5 enerated ’ This device stores one bit on its Storage node. It is composed 
p f ^^ transistors, Read-Gate, Write-Gate, and Storage-Gate, and six nodes, Bus, 
ead, Write, Storage, A, and Gnd. The Bus node, after being connected to many 
other cells, will have a larger capacitance than the Storage or A nodes; Read and 

o a /x>r mUt .I ia i. 7 excIusive - The net behavior of this device appears in Figure 8.2. 
iiie RAM cell has a temporal logical constraint of tmutex(Read„ Write,). This 
constraint is employed during steps 2 and 3. 
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Figure 8.2: Schematic of 3 Transistor Dynamic Ram. Bus, A, Storage, Write, and 

! w r ! ‘ Read ' Gate ’ Write-Gate, and Storage-Gate the RAM’s parts. Read* 
and Write* are not simultaneously asserted. 


8.2.1 Renaming Behaviors 

The net behaviors of a node’s subnodes 1 must be renamed to the structural level 
of the circuit whose net behavior is being generated. A net behavior equation is 
renamed by changing names local to the circuit’s subcircuits to names used by the 
circuit. The following algorithm is used to effect this: 

Algorithm RENAME: 

Inputs: A subcircuit C, its net behavior equations E, and its renaming table R. 

Outputs: New behavior equations based on E where names have been changed to 
refer to names used by C’s parent. 

Method: Replace each name N in E with its associated name in R. ■ 

For example, in the Three Transistor Ram, the Source, Drain, and Gate nodes of 
its three transistors must be renamed to its Bus, Write, Storage, Read, A, and Gnd 
nodes. The relationship between the names local to the Three Transistor RAM’s 
parts and its own local names is shown in Figure 8.3. 

,, again the behavior equations of the nMOS n-channel transistor (Ta- 

e 2.1j They use names local to the transistor. Renaming the behavior of the 

Read-gate, for example, yields equations identical to those for the nMOS transistor 
except for the names used: 

BuSfut —At. Read*(t) =>• [Bus A], 


™lv b Y de> "* thC n ° d “ ° f devkeS ° ne level down the hierarchy which 
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Gate 


Source 


Source 



Gate 


Drain 


Source 


Names local 
to the Three 
Transistor Ram’s 
parts 


Bus Bus 



Names local 
to the Three 
Transistor Ram 


Figure 8.3: Renaming the transistors of the Three Transistor RAM. 


NOT(Readt(t)) ^ [Bus] 
= A t. Readt(t) => [Bus A], 
N0T(Read»(t)) =► [A] 
Read,** = A t. [Read] 


The two other transistors are similarly renamed. 

8.2.2 Merging Nets 

When subnodes connect their possible nets must be merged together. The function 
Merge is used to merge nets. Let N and M be nets with edges N td „ and M tdat 
and nodes W™*, and A/*,*,, respectively. Then (Merge N M) = O where O tdftt = 

tdg*» U M tdg „ and On**# = N^, u Merge can be extended to expect an 

arbitrary number of arg umen ts. 

Behavior expressions are merged together using the following algorithm: 
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Algorithm MERGE NET EXPRESSIONS: 

Inputs: A node and the net behavior expressions of its subnodes. There is one 
expression per subnode. 

Outputs: An approximation to the net behavior expression of the node. 

Method: Apply the function Merge to the node’s subnodes’ net expressions. Then 
rewrite the resulting expression into standard form. An expression is in standard 
form when 1) the top level expression is a conditional, 2) all its predicates consist 
of node names and boolean operators, and 3) all its consequents are nets. Once 
m standard form, the temporal logical constraints of the circuit are used to prune 

logically disallowed clauses. A clause is logically disallowed when its predicate is 
always false. ■ 

For example, two subnodes connect to make the Bus node of the Three Transistor 
Ram. Two net behavior equations (one for each subnode) exist for the Bus node: 

Bus,** = A t. Readj(t) => [Bus A], 

N0T(read*(t)) =► [Bus]. 


Bus,** — At. write*(t) =► [Bus Storage], 
NOT(write*(t)) =► [Bus]. 


Merge is applied to the expressions to yield an approximation of the behavior 
equation for the bus node: 

busn«< = Merge(A t. Read*(t) => [Bus A], 

N0T(Read*(t)) =► [Bus]., 

A t. Write*(t) =► [Bus Storage], 

NOT(Write*(t)) => [Bus].) 

This equation is rewritten into standard form by forming the cross product of 
the clauses of the conditionals: 

Bus,** = A t . Read*(t) A Write*(t) =» Merge([Bus A], [Bus Storage]), 

Read*(t) A NOT(Write*(t)) =* Merge([Bus A], [Bus]), 

N0T(Read»(t)) A Write*(t) => Merge([Bus], [Bus Storage]), 
N0T(Read*(t)) A NOT(write*(t)) =* Merge([Bus], [Bus]) 


After executing the Merge’s we get 
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Bus,*, = A t. Read*(t) A Write*(t) => [Bus A Storage], 
Read»(t) A NOT(Write»(t)) => [Bus A], 
N0T(Read*(t)) A Write* (t) =► [Bus Storage], 
N0T(Read*(t)) A NOT(Write»(t)) =» [Bus] 


A simplifier now removes logically disallowed clauses. Because Read, and Write, 

asserted, the fort clause is logically disallowed and is 
removed. Note that a clause can be logically disallowed not only because of mutually 
exclusive signals, but also for any fixed relationship between signals. For example! 

if it were the case that either Read, or Write, were always asserted, then the last 
clause would be logically disallowed. 

Besides eliminating logically disallowed clauses, the simplifier also simplifies 
predicates to shrink them. For example, because Read, and Write, are mutually 
elusive, Read* implies N0T( Write*) and vice versa. The result of this simplification 

IS 


Bus*., _At. Read*(t) => [Bus A], 

Write*(t) => [Bus Storage], 

N0T(Read*(t)) A N0T(Write*(t)) =► [Bus]. 


Figure 8.1 shows the result of applying Algorithm MERGE NET 
to all the nodes of the Three Transistor RAM. 


EXPRESSIONS 


8.2.3 Expanding Nets 

Merging only solves half the problem of generating equations. Nets which span 
across ^ny devices (e.g., from the ground node to the Bus node of the Three 
Transistor RAM) must be found. The generation of behavior equations is com- 
pleted by iteratively applying a simple expansion transformation to each node. The 

expansion transformation expands the “boundaries” of the possible nets of the node 
to include adjacent nets. 

The expansion transformation replaces a chosen node Y in a net N by the ex- 

r a Tr 0n i+ 0r Y T THlS ends N to include possible-nets of Y. The replacement 
an result in the original net N being replaced by multiple nets. The replacement 
is very similar to the merging of nodes discussed above. 

Algorithm EXPAND NET BEHAVIOR EQUATIONS.- 

Input.: The approximate net behavior equation, for a circuit C that were created 
Dy Algorithm Merge. 

Outputs: The complete net behavior expressions for C’s nodes 
Method: 



CHAPTER 8. GENERATING NET BEHAVIOR 


130 

Bus,** — A t 

Storage,** = A t 
Anet = A t 

Read,** = A t 

Write,** = A t 


Read*(t) =>> [Bus A], 

Write»(t) =» [Bus Storage], 
N0T(Read»(t)) A NOT(write) =► [Bus] 
Writej(t) =>■ [Bus Storage], 
N0T(Write»(t)) [Storage] 

Readi(t) A storage t (t)=» [Gnd A Bus], 
Read»(t) A NOT(storage*(t)) => [A Bus], 
N0T(read»(t)) A storage 6 (t) => [Gnd A], 
N0T(read t (t)) A N0T(storage t (t)) =► [A] 
[read] 

[write] 


Table 8.1: Equations describing the net behavior of Three Transistor RAM after 

merging. These are not the final equations. Not all possible nets have been gener¬ 
ated. 


For the net behavior expression EX of each equation do 
Repeat 

Choose some net N of EX 

Choose some node Y in the N that has not been chosen before. 
Replace N by (Merge N Y,**). 

Rewrite EX back to standard form. 

Eliminate disallowed clauses. 

Until closure is reached (».e., nets stop expanding). ■ 


For example, consider Bus,** of Table 8.1. Choosing to expand node A in this 
expression results in: 

Bus,** = A t . Readj(t) A storage 4 (t) =» [Bus A Gnd], 

Readt(t) A NOT(Storage k (t)) => [Bus A], 

Write»(t) =>• [Bus Storage], 

N0T(Read*(t)) A N0T(Write»(t)) =► [Bus] 

Applying the transformation again for any other nodes in the possible nets of 
Bus results in no change, so this is the final, and correct, behavior expression for 
the Bus node. Repeating the expansion for the other nodes yields the final set of 
behavior expressions for the Three Transistor RAM Table 8.2. Because the A node 
is a connection node its behavior equation is not computed. 
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Bus^t -At. Readj(t) A Storage 4 (t) => [Bus A Gnd], 
Read 4 (t) A NOT(Storage 4 (t)) =► [Bus A], 
Write 4 (t) =>• [Bus Storage], 
N0T(Read t (t)) A NOT(Write 4 (t)) => [Bus] 
Storage^, = A t . Write 4 (t) ^ [Bus Storage], 
NOT(Write 4 (t)) =» [Storage] 

Read,^ = A t . [Read] 

Writer* = A t . [Write] 


Table 8.2: Equations describing the behavior of Three Transistor RAM. The A 

node is not represented because, as a connection node, its behavior expression is 
not computed. 


(As described net expansion is a very costly operation because the same nets 

W "V\ e I f* r 5 ed many times ‘ Silica Pithecus carefully keeps track of which mergings 
need to be done to minimize the number of mergings.) 







Chapter 9 

Net Behavior to Digital Behavior 


As explained in Chapter 6, Silica Pithecus abstracts a circuit’s digital behavior 
Erectly from the circuit’s net behavior. The translation from net behavior to sig¬ 
nal behavior and then signal behavior to digital behavior only occurs subliminally. 

Nonetheless, we will act as if the translation did occur: doing so simplifies the 
exposition. 

In the examples the outputs of a circuit’s signal behavior applied to the circuit’s 

• W w ab8 *IT te ?’ ? thiS Chaptef (a re P re8entat * on of) the signal behavior 
self is abstracted. Applying this abstraction to some inputs * yields the same 

result as abstracting the outputs of the original signal behavior applied to *. That 

ABS flTn were computing A I. ABS(B s (Design) (i)), we now compute 

ABS(S 5 (£>esiyn))(*). In the second expression ABS(B 5 (£>es*>n)) is applied to t 
We have made ABS polymorphic; here ABS is operating on functions, rather than on 
signals. Signal behavior itself is abstracted by constant folding the (representation of 
• 6 a . bstr * ctlon faction, ABS 5=>r , over the (representation of the) circuit’s 

neTbeha^w”* ^ Chaptersh ° W8 how ABS (B s (Design)) is derived from Design's 

The formal notation for describing the abstracted signal behavior of a circuit 
with N inputs (which are signals) and M outputs (which are digital values) is 

A 3 . S where = /^.o), ... ,o m = / m (3,o). 

The formai notation is rarely used. Instead, the equational part will be given; the 
an ?„ bo " nd and return values will be left implicit. An example appears 

in Table 9.1, which shows the abstracted behavior of the Inverting Latch 
Conceptually, the generation of ABS(B s (Design)) is a three step process: 

1. Constraints are generated from Design's net behavior, 

2. B s (Design) is generated, 

3. Bs (Design) is abstracted to yield ABS(B s (Design)). 
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During the first step flow and timing constraints are generated. During the third 
step threshold constraints are generated, and charge sharing bugs and ratio bugs 
are found and reported. In the implementation the steps 2 and 3 are intertwined 
to minimize the amount of detail of B s (Design) which is generated. 

., J be value at node X is denoted X»,. We retract the earlier statement 

that the digital values are 0,1, and float. 1 Instead, four digital values, called driven 
, driven 0, floating 1, and floating 0, are used. Digital values have two attributes, a 
boolean attribute and a floating attribute. Each attribute has two possible values, 
which gives rise to the four digital values. A digital value X*/ is denoted <X*,X/> 

tT'Sl d r n ° teS the b °° lean attribute of X and X, denotes the floating attribute 
of X. The four digital values are denoted <1,D>, <0,D>, <1,F>, and <0,F>. 

Two functions, B and F, are used to project the different parts of digital values 
B projects the boolean part, and F projects the floating part. 

The greater precision of the four value scheme is required. The three value 
scheme (0, 1, and float), though adequate for describing intended digital behavior, 
is inadequate as a target space for abstraction. The problem is that a signal may 
either be used for its boolean attribute or for its floating attribute. The abstraction 
function can’t know which attribute is desired by the designer and must return both 
attributes. The comparator is responsible for matching abstracted attributes with 
the designer’s intentions. A 1 intended by the designer is matched by either <1,D> 

or <1,F>. Similarly, a float intended by the designer is matched by either <0,F> 
or <1,F>. ’ 

Threshold constraints dictate that certain signals cannot suffer threshold drops. 
A signal that has suffered a threshold drop is called degraded. Threshold constraints 
ensure that ratios of nMOS gates will yield logically valid voltages. They also ensure 
t at voltage levels are aren’t made invalid by passing through pass transistors gated 
by degraded signals. The example of Chapter 3 indicated that threshold constraints 
were generated after B s (Design) was generated. This is not the case. Rather, 
threshold constraints are generated as Bs(Design) is generated. 


Example: Inverting Latch 


As a running example, this chapter shows how ABS(B$ (Inverting Latch)) (Ta¬ 
ble 9.1) is derived from the Inverting Latch’s net behavior. The net behavior of the 
Inverting Latch (Figure 1.3) is 

Out^t = A t . Sj(t) —* [Vdd, Gnd, Out], 

N0T(S»(t)) -+ [Vdd, Out] 

= A t . Latch*(t) —► [In, S], 

N0T(Latch»(t)) -+ [In] 


^he digital specification language still uses just the three values. But Silica Pithecus’s internal 
representations use the four value scheme. 
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Out*/ = B(S*/) <0,D> 

- ’B(S»/)) <1,D>. 

In*/ = ABS (In,) 

S*/ = B(Latch*/) - ABS(In,), 

-iB(Latch*/) ABS(S,). 
Latch*/ = ABS (Latch,) 


Table 9.1: ABS{B s {Inverting Latch)). X», denotes the digital behavior of X. 


Latclw 


= A t 


Latch* (t) -► [In, S], 
NOT(Latch*(t)) - [S] 
A t . [Latch]. 


The contraints issued while generating the above digital behavior are: 

1. falls (Latch,) => falls-first(Latch.,In,) 

2. control(Latch,) 

3. Latch* =► overpowers([In] /ft , [S] s ) 

4. no-drop(Latch,) 

(The generation of the first three constraints has been discussed (Chapters 4 and 5) 
This chapter discusses generating the fourth constraint.) 

Creating ABS (f? s (Design) ) and generating theshold constraints is conceptually 
simple. Starting from net behavior, each transistor in a net is replaced by its full 
model. If there are N transistors in a net this generates 3* detailed nets. A detailed 
net is a net where each transistor has been replaced by the resistor and threshold 
drop device which model one of the transistor’s operating regions (Figure 9.1 shows 
a detaded net). Each detailed net is then analysed to produce a combination of 
threshold contraints, abstracted voltage levels, and reports of actual design errors. 
Although 3 detailed nets are theoretically required, only about 2 N detailed nets 
actually need to be enumerated. 

This chapter has two sections. The first section shows the analysis of detailed 
nets. The second section presents the enumeration method for detailed nets which 
minimizes the number of detailed nets generated. 
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4R 



1 volt 


-Out 


1 R 


2 volts 



Figure 9.1: A Detailed Net 


9.1 Analyzing Detailed Nets 

During analysis each net spawns many detailed nets. The detailed nets are analysed 
to predict and abstract the voltage at a given node in the detailed net. When valid 
voltages occur they are abstracted to either 0 or 1. When an invalid voltage occurs 
either a threshold constraint is generated, a charge sharing bug is reported, or a 
threshold bug is reported.* 

A signal value is the value of a signal at some particular time. A signal value 
has two attributes, strength and voltage. Once all constraints have been issued and 
design errors caught, all signals are abstractable. Therefore no errors are reported 
when abstracting a signal and all that is left for the abstraction function to do is 
turn a signal’s final value into a digital value. The following function does this. 

Algorithm STD (Signal Value to Digital Value): 

Inputs: A signal value SV 
Outputs: A digital Value. 

Method: 

If SV is driven let strength be “D” else let it be “F.” 

If V > 3.5 then return <1 ,strength> 
else if V <1.5 then return <0 ,strength>. 


We now discuss determining and abstracting the voltage at a given node in a 
detailed net. When the final voltage of a signal S can’t be determined (because 

2 This ia overly conservative. If the designer depends only on the signal being nndriven and not on 
the signal s boolean value, then no error should be generated. Silica Pithecus could be changed to 
return a value denoting an invalid voltage. Then only when the designer depended on the value 
would an error be generated. 
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the voltage comes from stored charge rather than from gates), it is known, because 
ot constraints and assumptions of valid inputs, that the final voltage will be valid. 
Abstracting such a signal yields the symbolic result ABS(S). 

There are three cases to consider depending on the nodes in the detailed net 


Net co “ tains driven nodes. The driven nodes determine the final values of all 
the undriven nodes in the net. With one exception, nets may contain only 
one driven node. The exception is that a net may contain both Vdd and Gnd 
When a net contains both Vdd and Gnd, the network is transformed into 

an equivalent voltage divider using Thevenin equivalents. (Examples appear 
below.) 

Net contains no driven or input nodes. There are two cases to consider based 
on whether there is some node N whose capacitance overpowers the rest of the 
net. When N exists, the result of abstraction is the symbolic result ABS(N,). 

When N does not exist, data dependent methods must be used to determine 
if charge sharing will result in valid logic levels. These methods show that 
enough nodes have the same logical value such that the net settles to this 
ogical value. Silica Pithecus employs a simple heuristic to determine whether 
enough nodes will have the same logical value. It first determines the phase 
at which the net is activated (e.g., fa or fa). 3 It then determines the values 
of the nodes at the end of the previous phase. If enough of the nodes have 
the same value then that value is used. When not enough are the same, an 
error is generated. 

Net contains an input node I. Flow constraints guarantee that I is the domi¬ 
nant node. The voltage of a node other than I in net cannot be determined, 

* M/I\ St ^ aCtl ° n ° f a Signal anywhere in net is guaranteed to be the same 
as ABS(I j ). (Note that the term “input node" refers to nodes declared to be 
the inputs of circuits. “Input node” does not refer to driven nodes, as it does 

m other systems. There is no guarantee that an input node will be connected 
to a driven node.) 


9.2 Enumerating Detailed Nets 

A conducting transistor has three regions: full conductance (gate voltage of 5 volts) 
partial conductance (gate voltage above 3.5 volts), and unknown conductance (gate 
voltage between 1.5 and 3.5 volts). Theoretically, to predict the full behavior of 

3 On the next revision of this document I will explain where fa and fa came from. 
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a given net, the net must be instantiated with all ranges of its transistors’ behav¬ 
iors. Therefore predicting the behavior of a net theoretically requires generating 3^ 
detailed nets where N is the number of transistors in the net. 

However, by carefully enumerating the nets and by being conservative, 4 only 
2N detailed nets need be generated. There are two key observations. First, there 
is no need to create detailed nets where a transistor is in the unknown conductance 
region. By implicitly constraining all signals which gate transistors to have valid 
voltages it is ensured that transistors never operate in this region. These implicit 
constraints are checked as part of verification. This strategy reduces the theoretical 
number of required detailed nets to 2 N . 

Second, by judiciously choosing the order in which nets are enumerated, it is 
possible to set the operating region of transistor to just one of the two remaining 
region 8 it could be in. The region is set the first time the transistor is encountered. 
When a detailed net yields a valid voltage where transistor T is partially conducting 
then the net will yield a valid voltage when T is fully conducting. Therefore there 
is no need to generate the detailed net where T is fully conducting. It is only 
necessary to generate that net when the detailed net yields invalid voltages when T 
is partially conducting. In this case, a threshold constraint is issued to prevent T 
rom partially conducting and thenceforth T is always fully conducting. Therefore 
detailed nets where T is partially conducting need never be generated. These two 
strategies together, plus the rule that the possible nets of a node are analysed from 

smallest to largest, allow the analysis routine to generate only a linear number of 
detailed nets. 

[I must mention validifying use of foo» and must mention steadystate logical 
constraints here.] 

Example: Inverting Latch 

As an example we will generate ABS (£ s {Inverting Latch)) from Inverting Latch’s 
net behavior (Figure 9.2). We will analyze the behavior of each of its nodes in the 
order Latch, In, S, and Out. The result appears in Table 9.1. 

The first node to be analyzed is Latch. It has only one possible net, itself. There- 
fore, the abstraction of Latch’s signal behavior is the symbolic result ABS(Latch,). 

The second node to be analyzed is In. It has two possible nets. But because it 
is an input node, generated constraints guaranteed that In is the dominant node of 
all of its possible nets. Therefore the abstraction of its signal behavior is ABS (In,). 

The third node to be analysed is S. It has two possible nets. They must be 
analysed m detail. The smaller net is analysed first. This net is selected when 
voItage(Latch,(fy)) < 1.5 volts. B ecause the net has just one node 5, the abstrac- 

4 ^toThTvSr meanS ’ “ alWay8 ’ at the r “ k ° f “ troducin * a fcw more sources of false negatives 
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Not(%(t)) -> 
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Figure 9.2: Inverting Latch’s Net Behavior 
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tion of the net’s signal at node 5 is ABS(S,). The first of the two clauses of 5’s 
abstracted behavior expression is now generated. It is 


voltage(Latch,(t/)) < 1.5 =» ABS(S,). 

The predicate is equivalent to, and replaced by, ->B (Latch*/) to yield 

->B(Latch*/) =» ABS(S,). 

5’s other possible net is then analysed. The first detailed net generated uses a 
partially conducting Latch-Gate: 


In 


2 R 2 volts 

'Vv-Kb 


s 


Analyzing this detailed network yields a maximum voltage of 2 volts at 5 due 
to threshold drops. This is an invalid voltage, so a threshold constraint is slapped 
on Latch,. (This is the fourth, and final, constraint placed on the Inverting Latch.) 
In all future detailed nets this constraint will guarantee Latch-Gate is always fully 
conducting. The detailed net where Latch-Gate is fully conducting is tried next: 


In 


1 R 

Ab 


3.5 volts 

— 


s 


This net has no threshold problems. We employ the flow constraint that requires 
JH/n overpowers [S] 5 to infer that the abstraction of the signal at 5 is ABS(In,). 
Therefore, the second clause of 5’s abstracted behavior expression is 


voltage(Latch,(t/)) = 5 => ABS(In.) 
which is equivalent to is 

B(Latch*/) => ABS(In,). 

We therefore have 


S t/ = B(Latch*/) - ABS(S,), 
-B(Latch*/) - ABS(In,). 


The last node to be analysed is Out. It has two possible nets. The detailed net 
for the smaller net is 
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4 R 


5 volts 
-Out 


therefore yiCldS 5 ** ° Ut ' ° nC daUSe ° f ° Ut ’ S abstracted signal behavior is 

B(S»/) => <1,D>. 

The first detailed net for Out’s other possible net is 



2 volts 


Analysis yields 1 volt at Out. Out’s other abstracted clause is 

B(S»/) => <0,D>. 

There is no need to generate the other detailed net as it will yield a valid voltage 
when the pulldown is partially conducting. * 

We therefore have 

Out*/ = B(S t/ ) <0,D> 

~'B(S»/) -► <1,D>. 


9.3 Summary 

This chapter showed how AB8(B a (Design)) was generated from Design's net be- 
avior Silica Pithecus s method for determining the final voltages of nodes in 
detailed nets was given. When invalid voltages are detected Silica Pithecus issues 
an approbate threshold constraint, charge sharing bug report, or invalid ratio bug 
report. Silica Pithecus generates detailed nets from a node’s possible nets. Al¬ 
though exponentially many detailed nets can be generated for each possible net, 
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Chapter 10 

Hierarchical Verification 


I cla.m that despite the ubiquity of the word “hierarchical’ in many systems and 
theses, researchers have missed the major idea of hierarchical verification. A ver- 
ifier us a theorem prover, and hierarchical verification is a mechanism for focusing 
he theorem prover. An effect of focusing the theorem prover is vastly increased 

theglobai ^e mplLaaiMi ,he **** without understanding 

a f aP J' r h “ 5 r Ct ‘° nS ; The tet sec,i °" Pnaents hierarchical verification as 

verifier Verify f ° r pn ° b ' The s * cond 5econd discusses Barrow’s hierarchical 

enfier Verify. The thud section presents the interactions between hierarchical ver- 

he fourth Hierarchical digital verification is presented in 

in the fim, 5 * 01 , 10 ” Wlth hierarchical functional verification are discussed 

m the fifth section. 


10.1 Focusing Proofs 

Lt im A that fi VerifiCat i° n 18 formally P rovin * that certain predicates about a circuit 
A 7?*? n he ° j rem pr0Ver Which proves the predicates are true (or proves 
they are false). The predicates can be about physical characteristics of the circuit 

ir fimr? 1811 ! 11168 ’ electnc ^ Properties (e.g., all outputs have valid voltages), 
P . r ° perties ( e ' 9 -' the circuit « a 32 bit adder). In each of these cases, 
w^* deS,gn 18 repr . esented “My in terms of the interconnections of its primitives 
without any imposed structure, a theorem prover must wade through a massive 

fimeTo H m f i r atl0n / 0 r riVe * Pr °° f * The theorem P rover will require a long 
time to derive the proof, if it can find one at all. 

Large, complex designs are created by recursively compomng simpler designs 

^ C °“ P d “ ig “- Th ' StrUCture th >* and has been, 

mplmted toorganiMa correctness proof. A hierarchical verifier is a method of 

verification that establishes lemmas (subpredicates) about the design, then proves 
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P(Design) 



P(D1) 

P(D11) P(...) P(Dln) 


P(...) 

/ I \ 



P(Dnl) P(...) 

/ I \ 


P(Dnm) 

/ I \ 


Figure 10 1: Focusing a Proof. When described hierarchically, a design can be 
represented as tree. The leaves of the tree represent the primitive elements of the 
design and the nodes represent composition. Shared structure occurs when a node 

18 * rf 1016 , than ° ne ° ther node * 111 hierarchical verification, lemmas are 
established at nodes of the tree. These lemmas are used to establish the proof 
either the proof itself or other lemmas higher in the tree. 


the desired predicate from the lemmas. The lemmas are organised around the 
stractural components of a design. For some types of verifiers, such as design rule 
checkers, the lemmas can be automatically found (e.j., the inside of this cell is OK) 
For other verifiers such ss Verify or Silica Pithecus which are behavioral verifiers, 
tne le mma s must be provided by the designer. 

Hierarchical verification is shown pictorially in Figure 10.1. A hierarchical de¬ 
sign can be represented as a tree where the leaf nodes represent primitives (e.g., 
rectangles, transistors, switches, adders) and the nodes represent compositions (e.g., 
abutment, functional composition) of components. Structure can be shared, a node 

j °L m t ny ° ther nodes - Whereas a non-hierarchical verifier (hereafter 

called a flat verifier) would reason directly from the primitives and the meaning of 
compositions, a hierarchical verifier proves lemmas about nodes in the tree. These 

“Tf" ar % US !^ Pr ° Ve Iemmas further U P in the tree. Finally, the lemmas are 
used to verify the design itself. 

For example, when asked to verify an ALU, a hierarchical verifier would first 
verify that the low level cells, such as adder cells and comparator cells are correct, 
then it would prove that arrays of those cells are correct (using the knowledge 
that the cells are correct), then it would prove the ALU itself is correct (using the 
knowledge that the arrays of cells are correct). 

There are three major advantages of hierarchical verification. First, the inter- 
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mediate lemmas may allow a proof to be found where a flat verifier fails to find 
a proof. Second a component’s lemmas need only be established once, regardless 
of the number of times the component is used. Third, establishing lemmas causes 
errors to be pinpointed quickly and accurately. 

In regular designs a given component may be used many times. When shared 
nurture is used to implement the different instantiations of the component, lem¬ 
mas need only be established once for it (at the node in the tree which creates the 
component) A flat venfler is forced to implicitly reestablish the lemmas for each 
S^Tv Ce t a f component. This advantage, only establishing lemmas once, is 

The vab, f her /^^ Che f S “ th ' Primary ““‘"bution of hierarchical verification. 
The gam of establishing lemmas only once for a component depends on the regular- 

*° f “ lg "; " “i tr T !ly repllM ' desi *" components replicated many 

times there is a large gain, for less regular designs there is less gain. 

Establishing lemmas for components is equivalent to verifying those components. 

Ihkh‘i ng C ° mp0 ““‘ > brfora the w b°l« design finds errors incrementally, 

which is extremely important. Detecting bugs as they occur causes reevaluation of 

d , ‘ gm ’, “ «cly stage. Often a design flaw in a small segment of a design inval- 

s WMt M ° f th * dMlg ”' Detecti "* * he ®» w on| y after the design is completed 


10.2 Behavioral Verifiers: Verify 


To make these ideas concrete without introducing the complexity of dealing with a 
dengn s context, we will discuss how Verify [Barrowj, a hierarchical verifier! works 
Verify is a monolevel venfler that operates in the digital and arithmetics dom.b. 

tlomdd haa . tW °,‘ nPUt3 ' 1 8trul:t “ ral description of a digital design, and a func¬ 
tional description (i.e., a program) of the intended behavior of the design. Verify 

DMiM th^ht*™' by ‘ h * stcnctural description by functionally com- 

taZdJfn behaviors of the structure’s parts. It then compare, the derived and 

di!n„«o!^ a rT f " eq ' uvalenc «- K lI >e behaviors are equivalent, the structural 
P th b * * VaM im P l « m »““ion of the intended behavior. The 

exhtfiu, eKh node u tha * the behavior ° f 

Verify derives its power from its method for deriving a structure’s behavior. It 

d!Z2t h h * • beh »' ,ior » (‘he lemmas) of a structure’s parts rather than the 

drived behavior of the parts. The resulting behavioral description is far easier to 

manipulate and re«on about than the behavioral description that would have been 

herwise generated. For example, once an n-bit adder is verified as an adder, its 

b ba ™V“ be “*■“•* of its inputs, rather than a complex boolean formula 
of n-bit boolean vectors. 
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10.3 Hierarchical Multilevel Verifiers: The Prob¬ 
lem of Context 

hierarchical ™iUilevel verifiers, there is » potential confusion to 
different?*' 1 Th fK f re . two , Werarchies, the descriptive hierarchy which refers to 
fohtTad 3 ° f bebavl0ral descri P«°n, and the structural hierarchy which refers 
how a design is put together. When just the word “hierarchy” is used the intended 
hierarchy should be clear from context.) 

Monolevel verifiers assume a design’s behavior to be solely a function of the 

° f * he deslgn ’ s part3 ' and not a Action of the context of the de- 
sign. This assumption cannot be made for multilevel verifiers. Employing partial 
abstraction functions and specialised behaviors requires considering a dLgn’s con- 
“ te ™ lun * “» behavior: because a designer only cares about a subset 
°mptrtam^ b * ° f a dasig "’ the con,ext th »‘ gives rise to that subset is 

Nonetheless, just as hierarchical monolevel verifiers use the intended behavior 
of components when proving a circuit exhibits a given behavior, we would like to 

hL »h,» P l m " g muItUevel verification. Doing so is much more efficient 
^ h ' combmation of ‘be circuit's signal behaviors. How hierarchical 

multilevel venfiers operate will be described both graphically and algebraically” 

The relationship between multilevel verification and hierarchical multilevel ver¬ 
ification is shown graphically in Figure 10.2. In this figure the design’s concrete 

tutdre” ' 3 “Vr and T intended abs ‘r»ct behavior « on the right. The struc- 

The tSTt T!n° n V? “ d * he behavioral representation on the bottom. 
The task is to verify the top left corner (the structurally represented design where 

the concrete behaviors of the components are known) against the lower right hand 

t0°3i™ b‘1 ab3 ‘ r “* ° f the -bole dmign). There " tt ^ 

to perform this task .corresponding to paths A -> B -r C (flat verification) and 

behavto^hl v f 1lcatio, ‘)’ Fla ‘ verification first derive, the concrete 

b ,.° f *b* w b° e fr om its parts, then abstracts this behavior and compares it 

oonenreT * ‘ f"”' Hi “"cbical verification first verifies the com- 

ah,re» .’J h rv co ? pos ?’* he components’ intended abstract behaviors to derive the 

ab * b ^ a T'° f t th ' Wh °“ d “ ig "- derive description is then compared 
against the intended abstract behavior of the entire design. 

T his can be stated algebraically using the function compose, which forms the 
composition of its operands. 1 Flat verification shows that 

_ ABS (compose Mn (5 eon (A),. ■. ,B eon (£>„))(*)) 


X •r'"* 1 ' f ° r * ““ < ‘ P ' r “ OT ~ lOeribrtll. (H. 
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A 


D 


Bcon(Partl) — 

Multilevel Verification 

Bib(PartI) 

Bcon(Part2) 

w 

Bib(Part2) 


w 

Bcon(Partn) — 

w 

-► 

••• 

Bib(Parln) 


Composition 

of 

Concrete Behaviors 


Multilevel Verification 

-► 


* 

Bcon( Design) 

B 


Composition 

of 

Intended Behaviors 
Validation 

▼ 

Bib(Design) 

C 


ti fl It fi T * he rela T tlonsh ;P i betwee n multilevel verification and hierarchical mul- 
llevel verification. In multilevel verification (path A -> B C) the concrete 

the ibzZZlS le K C ° m ?° n ? nt8 co f P 08 ^’ the resulting behavior abstracted, then 
the abstracted behavior is validated against the intended behavior. In hierarchical 

multilevel venfi^tion (path A -*• D -* C) the structure’s parts are verified, the 

mten tf u ab8tra ^ behaviors are composed, and the resulting behavior 
validated against the intended abstract behavior of the whole. 
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Bib {Design) (ABS (*)). 
Hierarchical verification shows that 


compose^iBjBiDi) . B tB {D n )) = B IB {Design). 


Hierarchical verification is valid only if it yields the same result as flat verification 
That is^ntytf A ~* B ~* CandA -* D -* Cof Figure 10.2 yield the same result). 


ABS(compose eon (B ( . on (i!? 1 ),..., B con (£>„))(?)) 


compose^iBniDJ ,... ,H /fl (£> n ))(ABS(*)). 

We claim that they are equivalent when the satisfaction of Design's constraints 
imply the satisfaction of Design's components’ constraints. 

nn ^ w n0t f0rma11 ^ Pr ° ve this claim ’ to do 80 w <>uld require putting compose 

statemen t sketch a P roof of a simplified version of the 

statement. This sketch uses the function UNABS. UNABS takes an element of 

^ f etUmS “ eIement of the concrete domain - The element 

UNABSrlls?^ u k ? “ VX e a MABS(UNABS(*)) = X], In the sketch 
UNAB s (A bs (J 5Q) will be substituted for X. In general, this is not a valid substi- 

t W° n ' w gUar * nte ?’ , however > that an y unabstracted value is later abstracted so 
that no information is lost. 

In the sketch Design has N components, D x through D n . We begin with the 
abstraction of the compositions of the concrete behavior of the components: 


ABS (compose^iB^Di ),..., £ eon (£> n )(»)). 
The outputs of each component are abstracted then unabstracted: 
ABS(compose eon (\ j . UNABS(ABS(£ e<m (A)(}))), 

A 3 . UNABS(ABS(B eon (I? n )(3)))) 


Each occurrence ofABS(B ai ,(A)(3)) is replaced by A’s intended abstract behavior. 

is replacement is only valid when the constraints on D t are satisfied. For this 
reason, the satisfaction of the constraints on Design together with the physical 
construction of Design must imply the satisfaction of the constraints on each D 
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ABS 


Bcon(Dl) ◄- 


Bcon(D2) -4- 


A 

' i 


ABS 


nuw \ 

* ^^V NABS(ABS(8con(Dl) < i1 ))>^V^NABS(ABS(Bcon(D2)(i2)))- 


A 

i 


ABS 


oww « 

" Y< t UNABS(Bib(Dl )(ABS(i1)))*-A ljUNABS(Bib(D2)(ABS(i2))) 


A 

i 


^ ASS UNABS ABSUNABS . nQ 

*" - Bib(Dl) <«- Bib(D2) 4- ABS 


A 

i 


Bib(DI) 


Bib(D2) <4 -*§§_f 


Figure 10.3: Deriving 

ABS {composeconiBsiDJ, B S (D 2 


compose^, (B ib (Dj) , B ib (D 2 )) ABS ( 
))(*)) 


*) 


from 



ABS(compose eon (A j . UNABSfB^D^ABStf))), 

* * * 5 

A j . UNABS(B 7B (D n )(ABS(3)))) 


' ABS(UNABS(I)) •» »»w eliminated. This step hae two 
major results. Fust, all occurrences of UNABS vanish. Also, the only remaining 

tem^n3 Tht “* ° n th ! 40 the design itself ’ “* wy ln- 
no mornTn.^ 0ccumnc “ b ‘ “““‘ad and moved onto i. Second, because 

mth^h* 88 TT v” * ny mlen “ l liM *' lb “ trac * bnbavior is being composed 
ABs” ielT C ° n behavior. These eliminations of UNABS and transferences of 


composed, B (D t ) .B/*(A,))(ABS(8)), 

component design in Fig- 


Q.E.D. This proof sketch is shown graphically for a two 
ure 10.3. 



150 


CHAPTER 10. HIERARCHICAL VERIFICATION 



Figure 10.4: A Shift Cell. This circuit is made of two Inverting Latches. 

10.4 An Example of Hierarchical Digital Verifi¬ 
cation 

fFimr.T^ P i'H hi ' rar '““ 1 <“*“*1 verification* w. will show how a Shift Call 

vlrifW f b ,v ° ° f InVCrting Latches is verified. (An overview of the 
verification of this circuit was shown in Chapter 1.) 

The intended digital behavior of the Shift Cell is 

(df (SHIFT-CELL si s2) 

(let ((Left (INVERTING-LATCH si)) 

(Right (INVERTING-LATCH s2))) 

(lambda (in 11 12) 

(Right (Left in 11) 12)))) 

ThU digital specification says that the behavior of a Shift Cell is equivalent to two 
inverting latches, one feeding the other. 

thu^dT,^ ““‘n™* fM the >hift “ U: ‘““‘“(H.. L2.). It declares 

f7 *" mUtUaIljr exMn - Thlt »* *>° »» both Ll. and 

L2, asserted. This constraint wiU be used to satisfy some of the Shift Cell’s parts’ 

The verification condition is shown “graphically’* in Figure 10.5. In this figure 
}ound are , constraints derived during verification and INVERTING LATCH 
represents the intended digital behavior of the Inverting Latch. The verification 
condition is shown graphically rather than algebraically to stress that, in Silica Pi- 
thecus, the comparison of abstrac ted behaviors and intended abstract behavior of 

Savior and diS T?* 3 "* 1 verificakio “ wher « “8*al behavior is the concrete be- 

navior and digital behavior u the abstract behavior. 
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Figure 10.5; The Verification Condition for the Shift Cell. P„ md are the constraints 

denved during verificatton. INVERTING LATCH represents the intended digital 
behavior of the Inverting Latch. 6 


a circuit is done structurally (cf. Chapter 
in four steps. 


The verification condition is proved 


bv t6 j? \V Gene # rate ?! C L Tl? intS which alIow M Inverting Latch) to be replaced 
7 Bib (Inverting^ Latch) . These are generated by mapping the constraints of each 

of netTr ° f the Invertln 8 Latch - Mapping of constraints is similar to the mapping 
of net behaviors Section 8.2.1). Table 10.1 shows the generated constraints. (These 

in F^gme 1 . 4 !) compared with constraints of the Inverting Latch shown 

Step 2: Process the constraints. Each constraint is either accepted, rejected, or 
propagated. Chapter 11 discusses processing constraints. 


Accepted Constraints: Three of the above nine constraints are satisfied: 

• L2* A-iSl* =► overpowers([Gnd, C] c , [S2] s ,) 

• L2» A SI* => overpowers([Gnd, Vdd, C] c , (S2] sj ) 

• falls(L2*) =► falls-first(L2„ C,). 
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Mapped Constraints for Left 

Mapped Constraints for Right 

control(Ll.) 

no-drop(Ll.) 

Lh => overpowers([Inj /n , [Sl] 51 ) 

falls(Ll») =► lalls-llrstfLl.Jn.) 

control(L2.) 

no-drop(L2.) 

L2» A- 1 SI 4 =* overpowers([Gnd, C] c> (S2] S2 ) 

L2» AS1» => overpowers([Gnd, Vdd, CU, [S2]„) 
i.ll.(L2.) * Jalla-firstfL 2 .,cll 


Table 10.1: Mapped Constraints of the Shift Cell 


The first two are satisfied because Gnd and Vdd have infinite strength whereas 
2 has finite strength. The third constraint is satisfied because the logical con¬ 
straint tmutex(Ll„ L2.) with the constraints controlfLl.) and controlfL2 ) 
ensure that L2. falls before C, can change. 1 ' 

Rejected Constraints: None of the constraints are rejected, shown to not 
hold. 


Propagated Constraints: The remaining six constraints are propagated to be¬ 
come the P foun4 of the proof: 


• Llj =* overpowers([In] /n , [Sl] 51 ) 

• control(Ll.) 

• control (L2.) 

• no-drop(Ll.) 

• no-drop(L2.) 

• falls(Llj) =» falls-first(Ll„ In.) 

When the Shift Cell is used these constraints are processed. Constraints 
passed up the structural hierarchy until they are satisfied or rejected. 


are 


Step 3: Replace each occurrence of B s (Inverting Latch) by INVERTING LATCH 
and slide ABS from the output to the inputs. 

Step 4: Compare the two structures. They are the same, so the it is concluded 
Q*ED ** mPUtS ABS(i?5 ( Shift Cell X 5 )) = (Shift Cell)(ABS(t)), 


10.5. PROBLEMS WITH HIERARCHICAL FUNCTIONAL VERIFICATIONS 



Figure 10.6: 3-Bit Adder 


10.5 Problems with Hierarchical Functional Ver- 
ification 


®« tra Problems 3 in performing hierarchical functional verification 

tTon of tL t n t r f f StraCt d °r aiM (e ’*’ SetS> numbers ’ addresses, or a collec- 
xon of these types) of functional verification. One of the additional difficulties is 

compound data. Compound data prevents a component’s concrete behavior from 
being replaced by its intended behavior. 


10.5.1 Compound Data 

ab8t ^ b€havi0r0fade8ign imposing its components’ intended 

its own b T1 ^ S po88lble becaus€ every output of each component had 

a straioh If behavior - F ° r CirCUitS ™ th ganged outputs ( 8Uch M vecto « of bits) 
fails f ° substitution of intended abstract behavior for concrete behavior 

. < j° nsider a l' hit adder which returns a 4-bit result (Figure 10.6). 
h U ,° ut ° f the adder cel1 verified in Chapter 3 (Figure 3.3). We 

proved that the boolean and arithmetic behaviors of the adder cell were related by 
the equation 

Vies* {Boolean(i u i 2 , * 3 ) =► 

ABS(sum(t 1 , *j, * s )) + 2ABS {carry[t u i 2| * s )) 

__ = ABS(it ) + ABS(*j) + ABS(*s)}. 

“ “• “ I®”—. Oft.. »krt i. tapon... 

struct .1 r/, e . V1Ce t U ' mat ^ e ! natlcal "‘ructure underlying it* behavior. When thia matheLitical 

- ™ ‘T l f j"^lV J ' P !‘ f * ”5 "P ,itl “ r M « **k. • *«T Ion. Ita.. Th. 
reader is referred to (Barrow) for a discussion of this problem. 
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(Thw equation will be used as a lemma in the verification of the 3 -bit adder.) The 
difficulty is that neither sum nor carry can be replaced by some function solely of 
the abstracted inputs to the adder. Either must be replaced in terms of the other. 
The intended functional behavior 4 of the 3-bit adder is 

Bib (3-bit Adder) = A a b . o + 6 . 

h* 11 *™ 1 6ra> >t» components’ concrete behaviors. 1 
b .rr." th '" abjtraCted ' Wh «" ^Paring the abstracted and in- 

as a u™ n«tsir °" C ° nditi ° n ““ ““ “ 

beh^vt C ont“r ° f ^ 3 - W ‘ adder> deriVed " 

Bb* (Adder Cell) = 

A [Ao, Ai, At, A 3 ] [Bq, B\, B 2 , B 3 ] . 

[5um(A 0 ,B 0 , false), 

Sum{Ai,Bi, Carry(Ao, B 0 , false)) 

Sum(A 3 , B 2 , Carry{A u B x , Carry(A 0 , B 0 , false))) 

Carry{A 2 , B 2 , Carry(A u B u Carry{A 0 , B 0 , false)))]. 

iJouL^Tf 16 r.Tr 1 ' Restructuring of formal parameters. This function’s 
vectors.*** * VeCt °"' Destructurin 8 each bit in the input 

The abstraction of the adder’s concrete behavior is 

vUBQfc“ r 7 ( ‘ , ' Jl A Car 7 (, '’ Jl ’ CarrV( ‘"’*' fll **)))) + 

ABS(^ u m(ti > Ji , Carry (to, j 0 , false))) + 

2 ABS(5um(t 0 ,jb,false)). 

u* T, 0f lh ' abstr “ ti0 » of «*• inputs, namely 
(2 ABS(i,) + 2ABS(*i) + ABS(to)) + (2 J ABS (j 2 ) + 2ABS(ji) + ABS(jb)). 

Therefore, the verification condition to be proved is 


Vu. 


.,i»€B*{Booltan( i) 


9 * An«/? ar 7^*-*A Car 7.^’^’ Carry (*°» *» *»!■•))))+ 

2 ABS(5ttm(»2, j^^orry^b, j^C grry^Q,^, falss))))+ 

What do “ ‘ + ’ mean? Fortunately, the adder’s output vector is 
bit longer than the adder’s input vectors so that the normal meaning of + is retained Had 

£cS? Tf™ bMn tH< 8am * k “ gth ’ »<* have betnOne must 

5 " eful to not faU mto the tra P of «»u>g standard operaton in non-standard ways. 

8 I find it hard to say whether flat verification or hierarchical verification is being performed It 
ar s out as flat verification, but, by using lemmas, starts to look like hierarchical verification. 
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2 1 ABS(5um(t 1 ,j\,C arry (t 0 , jo, f alse))) -f- 
2°ABS(5um(t 0 , jo, false)) 


2 J ABS(t 2 ) + 2ABS(tO + ABS(t 0 ) + 2 2 ABS(jh) + 2ABS(j 1 ) + ABS(jb). 

There are three alternatives. The first is to expand out the calls to Sum and 
Carry and use exhaustive methods to prove the equivalence. Although this strategy 
would work for the 3-bit adder, it fails as adders get larger. The second alternative 
is to replace the abstraction of the concrete behaviors of with the intended behavior 
of the outputs. But as mentioned earlier, this alternatives fails because the outputs 
are_ interrelated and are not eliminated by this approach. The third alternative is 
to be intelligent about which of Sum and Carry to eliminate. 

We will rewrite the verification condition of the adder cell as 

ABS(sum(t 1 , tj, * s )) = 

ABSfo) + ABS(tj) + ABS(*j) - 2ABS( earry(i lt * 2 , t 3 )). 

This equation is used to eliminate the Sums from the verification condition of the 
3-bit adder to yield 

8 ABS(Carry(t 2 , jj, Carry(i u j u Carry(i Q J Q , false))))+ 
of + 4 ^ BS 0*) + 4 AB S ( carr y (* 1 , jj , carry (t'o, jo, false))) — 
SABSlcorry^jj^.carry^.ji.carry^o.jij.false))))-!- 
2ABS(t 1 ) + 2ABS(jj) + 2ABS(corry(t 0 , jb, false))- 
4ABS(carry(t 1 , jj, carry(i 0 ,j 0 , false)))+ 

ABS(t 0 ) + ABS(jo) + ABS(false) - 2 ABS (carry (t 0 ,jb, false)). 


4ABS(t 2 ) + 2ABS(* 1 ) + ABS(t 0 ) + 4ABS(ji) + 2ABS(j!) + ABS(jo). 

This is equivalent to 

4ABS(*j) -(- 4 ABS(j 2 ) 

2ABS(*!) + 2ABS(ji) 

ABS(t'o) + ABS(jb) + 0 


.. , . 4 ^ BS (*2) + ZABSfo) + ABS(*o) + 4ABS(ji) + 2ABS(j x ) + ABS(jb), 

which is true. The 3-bit adder is therefore correct. 

** a “ pI * shows that verifying a simple arithmetic unit requires some 
thought. With the nght approach, (•.«., eliminating Sum) the proof is simple, 
without it the proof is considerably more difficult. Because of the thought required, 
not all verifiers do this proof algebraically. For example, Verify [Barrow] does this 
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proof structurally 6 This example is indicative of validation at the functional level: 
otten nontrivial theorem proving must be done.) 


6 SarT^ n ;: Iedge ° f th * ref r SenUti ° n ° f nUmb «" M vecto ” of *> «*«* the proof: 

is hardwired to recognise predetermined structures as correct implementation of adders. 



Chapter 11 
Constraints 


Silica Pithecus’s constraint system is the key to Silica Pithecus’s hierarchical opera¬ 
tion, and therefore the key to Silica Pithecus’s speed. Constraints direct a circuit’s 
analysis. They change the nature of analysis from “what does the circuit do?" to 
does the circuit do the correct specific thing?" (Such as “do signals flow in right 
direction here?" or “does signal A fall before signal B?") Such questions are fo- 

cused and efficient to answer, whereas “what does this circuit do?" is unfocused 
and inefficient to answer. 

Each type of constraint has it own special theorem prover, called a handler, 
for proving instances of the constraint are satisfied. The handlers for logical and 
threshold constraints are algorithmic and will always get the right answer when 
they terminate. The handler for flow constraints is heuristic. It runs fast and 
works for nearly all circuits. The handler for timing constraints (stable-after and 
falls-first constraints) is heuristic and fails for circuits which rely on races. The 

heuristic handlers only generate false negatives when the fail, they never generate 
false positives. 

Constraints are mapped from the level of the component they are on to the level 
of the design being verified. Constraint mapping mirrors net behavior mapping 
w ich was presented in section 8.2.1: nodes and signals are renamed to use 
local to the design. Constraint mapping will not be explicitly presented. Examples 
of constraint mapping appeared in section 10.4. 

Each constraint is either accepted, rejected, or propagated. A constraint is ac¬ 
cepted once it is satisfied (shown to hold). A constraint is rejected when it is shown 
not to hold. Rejected constraints are returned to the designer. A constraint is 
propagated when it is neither accepted nor rejected. Propagated constraints are 
attached to the circuit being verified. The propagated constraints will be processed 
when the circuit is used as a component in a larger circuit. 

This chapter discusses each type of constraint in turn. 
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11.1 Logical Constraints 


The two types of logical constraints are steady state logical constraints and tempo¬ 
ral logical constraints. Steady state logical constraints predicate boolean relations 
between the final values of signals. 1 Temporal logical constraints predicate boolean 
relations between the values of signals at all points in time. 

A steady state logical constraint is either a signal name, or a boolean combina¬ 
tion (using A, and V) of steady state logical constraints. 2 When just a signal 
name it used as a steady state logical constraint it asserts that the signal’s final 
value is true. Steady state logical constraints correspond to propositional logic. 
Some complex predicates are named. For example, mutex(x, y) is shorthand for 
(->z A ->y) V (-.X A y) V (x A -iy). 

The most commonly used temporal logical constraint is tmutex. tmutexasserts 
that at no time is more than one of its arguments asserted. A special purpose 
method is used to satisfy temporal logical constraints. We require that all signals 
in a tmutex constraint be control signals. Then we show the signals are mutex when 
all the clocks are low and when each clock is high. 

Silica Pithecus does not propagate logical constraints, therefore a design must 
directly satisfy all its components’ logical constraints. 3 It can do this either struc- 
turolly oTlogicaUy. A constraint is structurally satisfied when it is satisfied because 
of the behavior of the components in the design. A constraint is logically satisfied 
when it is satisfied because of one the design’s logical constraints. For example, 
consider a component C with two inputs x and y and with a steady state logical 
constraint of x V y. Figure 11.1 shows this component used in two different designs. 
Design Dl structurally satisfies x Vy (which maps to a V6) because b = ->a). Design 

D2 logically satisfies x V y (which maps to c V d) because c V d is implied by £>2’s 
logical constraint c. 

Silica Pithecus does not propagate logical constraints because it wants to main¬ 
tain user level consistency. For reasons previously discussed, Silica Pithecus does 
not generate logical constraints, the user must supply them. Logical constraint 
propagation is similar logical constraint generation: constraints which the designer 
did not explicitly create get automatically created and attached to designs. It 
would be confusing to the user to have Silica Pithecus automatically create some 
constraints but not others. Therefore, Silica Pithecus doesn’t propagate logical con- 
straints. (On another note, not propagating logical constraints speeds verification 


1 J° ** P reciae > w « shoal <f say the predicate boolean relation* between the boolean interpretation of 
final value* of signal*. In this chapter we won’t be careful about making the distinction between 
signal values and tneir boolean interpretations. 


^(notTJdx y^))* nCW Predkate *' Forexam P le ' there “ no (defpredicate (at-moat-one 

3 A design directly satisfies a constraint when the 


constraint doesn’t need to be propagated. 
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Logical Constraint: C 


Figure 11.1: Designs must directly satisfy their components’ logical constraints. 

omponent C s steady state logical constraint, x V y, must be satisfied by any 
design C is m. Design D 1 structurally satisfies xVy (which maps to a V 6) because 

u De 5T D2 1 J ° glCally sat ! sfies xV » ( which map® to eVd) because c V d is 
implied by D2 s steady state logical constraint e. 


and simplifies the implementation.) 

Silica Pithecus uses a simple predicate calculus theorem prover to satisfy logical 
constraints. The kernel of the theorem prover was taken directly from the Lisp 1.5 
manual [Lisp 1.5). The theorem prover, invoked by the procedure prove, has two 
inputs: the predicate to be proved, and an environment of assertions, prove returns 
true the predicate can be proved from the assertions, otherwise it returns false, 
lhe following algorithm processes steady state logical constraints. 

Algorithm Process Steady State Logical Constraints: 

Inputs: Design D, its components’ mapped steady state logical constraints CLC, 
and its own steady state logical constraints LC. 

Outputs: A list of the unsatisfied CLC. 

Method: Label each wire (node) W { between components of D with the boolean 
formula representing the value on W<. For each CLC,, replace each wire (node) 
name with the wire s label to yield a new constraint CLC', If prove (CLC', LC) 
returns false add CLC, to the list of unsatisfied steady state logical constraints. 

. Fo [ consider again the designs of Figure 11.1. These designs have their 

wires labelled according to the boolean functions output by components driving 
the wire. Cs mapped steady state logical constraint, a V 6, is satisfied by Dl 
because prove(o V -o, {}) returns true. Similarly, C’s mapped steady state logical 
constraint, c V d, is satisfied by D2 because prove(c V d, {c}) returns true 
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Figure 11.2: Processing Threshold Constraints 


11.2 Threshold Constraints 

A threshold constraint on a signal is satisfied by showing that every final net com¬ 
puting the signal yields either a voltage of 5 volts or a voltage 1.5 volts. For example, 
consider the output of an inverter A driving the input of a minimally sized inverter 
. t Flgure n - 2 )- Because B is minimally sized, there is a threshold constraint on its 
input. B’s mapped constraint is no-drop(Intemal). The net behavior of Internal 
is the mapped net behavior of A’s Out node. This net behavior is: 


Out,** — At. Inj(t) —► [Vdd Out Gnd], 
N0T(In*(t)) - [Vdd Out]. 


The first net yields 1 volt, the second yields 5 volts. Therefore the threshold con¬ 
straint is satisfied. 

(A note on the implementation: Silica Pithecus doesn’t check threshold con¬ 
straints by examining net behaviors during constraint processing. Instead, checking 
whether a node puts out an undegraded signal is done at abstraction time and the 

result remembered. This saves repeated checking that would occur for a gate with 
large fanout.) 


11.3 Flow Constraints 

Mapping flow constraints is complex and expensive, but processing the mapped 
constraints is simple. Each is discussed in turn. 
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Left 

Figure 11.3: A Shift Cell 


Right 


We will use the Shift Cell of Chapters 1 and 10 (Figure 11.3) as an example 
of mapping and processing flow constraints. This device has two components, Left 
and Right, which are Inverting Latches. It also has a temporal logical constraint of 
tmutex(Ll, L2). The Inverting Latch has a flow constraint of 

Latch* =*► overpowers([In] /n , (S] 5 ). 

(A note on the implementation: constraint mapping and processing are inter¬ 
leaved. This prevents extraneous work and extraneous net expansion. Interested 
readers are invited to look at the code.) 

11.3.1 Mapping Flow Constraints 

Flow constraints are mapped in two steps: 

1. Rename the nodes used in the constraints. 

2. Expand nets named in the constraints. 

The first part, renaming, corresponds to what we have been calling mapping for the 
other constraints: names local to the component are replaced with names used by 
the design. The second part, expansion, is complex: it finds all nets which go into 
and out of an input node. When a constraint is expanded, it may turn into multiple 
constraints. (For example, consider the mapped flow constraints in Table 10.1.) 

Renaming Flow Constraints 

A flow constraint is renamed exactly as a net behavior expression is renamed 
(cf. Section 8.2.1). We will show how the flow constraints of the Shift Cell’s two 
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components is renamed. The Inverting Latch’s flow constraint is 

Latch* => overpowers([In] 7n ,[S] 5 ). 

This is renamed to 


Ll, * ov.rpo«.r.([In] /n ,[(S 

for the Left Inverting Latch, and renamed to 

Ll* =► overpowers([C] c ,[(S Right)] (5JK#w) ) 

for the Right Inverting Latch. The notation (<node-name> <instance-name>) 
is used to name components’ internal nodes (ef. Section 6.2). 

Expanding Flow Constraints 

The basic idea is to find the nets computing signals going into an input node, 
and the nets that those signals must drive. Once each set of nets are found, their 
cross-product is found and becomes the mapped constraints. 

For example, consider the Left’s output signal. There are two nets which com- 
pute this signal, [Vdd, Out, C], and [Vdd, Gnd, Out, C]. These nets occur on 
and ( S Left )»> respectively. There is only one net to be overpowered, 

[(S Right)]. The cross product of the “drivers” with the “drivees” yields the two 
constraints 

• L2» A -.(S Left), =* overpowers([Vdd, C] c ,[(S Right)] (5JKffc<) ) 

• L2* A (S Left), =► overpowers([Gnd, Vdd, C] c ,[(S Right)] (SJKfW) ). 

We now discuss the details of expanding flow constraints (».«., how to locate 
the driver” and and “drivee” nets). Expanding flow constraints is similar to the 
second and third steps (net merging and net expansion) of net behavior generation 
(Chapter 8). Constraint expansion differs in that after merging, certain nodes are 
dropped from nets before expansion to avoid having the expansion include the nets 
the must be overpowered (or must do the overpowering). 

Consider the constraint P =» overpowers (Net 1*^, Net2 No<U7 ). The following 
rules find the “drivers.” 

1. Perform Net Renaming and Merging for node Node 1 to yield X. 

2. Delete all nodes from Net2 from all nets of X. 

3. Perform Net Expansion on X. 
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Analogous rules are used to find the “drivees.” The cross product of the two net 
behavior expression is then generated. For every possible combination of a clause 
l -*• Net 1 from the “drivers” and a clause P2 -*• Net2 from the “drivees ” the 
constraint P A Pi a P2 overpowers(Nett, Net2) is generated. If P A Pi AP2 is 
logically disallowed then the constraint is ignored. 

Using these rules, the following flows constraints of the Shift Cell are the result 
of mapping the flow constraints of the Shift Cell’s components: 


Ll » =*► overpowers([In] /n ,[(S Left)] (Wf) ) 

L2» A -n(S Left)* =► overpow«rs([Vdd, C] c , [(S Right) 

L2» A (S Left)* =► overpowers([Gnd, Vdd, C) c ,[(S Right)] (JJHffct) ) 


11.3.2 Processing Flow Constraints 

The result of constraint mapping is a set of flow constraints. Each has the form 
overpowers(iVea, Net2). Not considering input/output nodes, an overpowers con¬ 
straint is accepted when the combined strength of the nodes Netl is ten times 
greater than the combined strength of the nodes in Net2. Otherwise the constraint 
is rejected and a charge sharing error returned to the designer. 

When either net of a flow constraint contains an I/O node (*.«., a node that is 
either an input or an output of the circuit being verified) then the constraint may be 
propagated rather than accepted or rejected. Specifically, a flow constraint cannot 
be accepted if the net to be overpowered contains an I/O node, and it cannot be 
rejected if the overpowering net contains an I/O node. 


11.3.3 Another Example: A Faulty Circuit 


As an example of a constraint that cannot be satisfied because of a buggy circuit con¬ 
sider connecting the Latched Inverter to the Inverting Latch, shown in Figure 11.4. 
The constraint to be mapped is the same as in the previous example: 


Latch* =* overpowers ([In] /r| , [S] s ). 
The net behavior of the C node is 


Gnet — At. Ll*(t) A In*(t) -+ [Gnd Vdd C (S left)], 
Ll*(t) A-i In*(t) - [Vdd C (S left)], 

- Ll*(t) - [C]. 


Therefore the constraint maps to the following three constraints: 
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Figure 11.4: A Faulty Circuit. The error in this circuit is caught by a rejected flow 
constraint. 


• L2» A Ll» A In* => overpowers([Gnd Vdd C (S left)] c , [(S Right)] (5JKfW) ). 

• L2» A Ll» A -'In* =► overpowers ([Vdd C (S left)] c ,[(S Right)] (5JW#Jk|J ). 

• L 2 * a -LI, overpowers([C] c ,[(S Right)] (5Jl ., w) ). 


When the last clause is true Ll* is false and L2* is true), then [CL 
must overpower [(S Right)] (5JllVW) ). Unfortunately, both C and (S Right) have the 

-same capacitance, so this constraint is not satisfied. Silica Pithecus reports this as 
a charge sharing bug. 


Note that had there been a logical constraint of, for example, either (Ll A L2) V 

A ->L2) or “'(-'Ll A L2), then the erring condition would not have arisen, and 
no error message would have been generated. 



Chapter 12 
Future Research 


This research engenders two kinds of future research: extending the theory and 
implementation, and looking at old problems in new ways. 


12.1 Combinatorial Blowup 

/ 

The major (pragmatic) deficiency is the brute force nature of the theory. There are 
many common circuits for which the number of possible nets is large. For example 
the output node of a 32-input nor gate has 2« possible different nets. The outputs 
of large PLA s have even more possible nets. To overcome this problem special 
code must be written for gates with large numbers of inputs. This code would only 
generate the minimal number of nets needed to catch ratio and threshold problems. 

Combinatorial blowup also strikes when discharging logical constraints. When 
the inputs to some device comes from a large PLA, discharging the logical con¬ 
straints can be very expensive. A smarter theorem prover must be employed which 
has heuristics for quickly proving constraints hold. 

1 believe that there are only a few general areas where combinatorial problems 
bite and that special case code can be written to solve 95% of the problems. 


12.2 Feedback 

Feedback was completely ignored. Silica Pithecus can detect static feedback. How¬ 
ever, it does not detect transient feedback. I do not believe that making it detect 
transient feedback is hard, it just hasn’t been done. 
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Figure 12.1: Two Three-Transistor RAMS 


12.3 Circuit Timing 


A timing estimator/verifier built on top of Silica Pithecus would be more accu- 

f**® o 648161 t0 U8C than other 8tatic verifiers 8uch as Crystal [Crystal] or TV 
[TVJ. Because the logical structure and signal flow of a circuit is accurately known, 
ere is more information to exploit to avoid approximations and potentially failing 


For example, a timing system embedded in Silica Pithecus would not need special 
scans or treewalks of the circuit to determining the “direction” of transistors. Other 
timing systems either scan the circuit or use hints from the designer to determine 
the direction of transistors. Crystal uses hints from the designer. Unfortunately, 
hese hints are not checked. The hints to Crystal are similar in intent to Silica Pi- 
ecus s logical constraints. Silica Pithecus checks the designer’s logical constraints, 
however, and Crystal doesn’t check the designer’s hints. If the designer gives Crystal 
the wrong hints he will get back the wrong answers. Also, TV’s determination of 
transistor directions is not guaranteed to be correct. If the determination is incorrect 
wrong timing results will be obtained. 


What confuses other timing verifiers is not knowing the possible nets of a cir¬ 
cuit. Because Silica Pithecus keeps track of possible nets with a vengeance, timing 
analysis and critical path analysis can be very precise. 


12.4 Capacitance Coupling 

Ignoring capacitive coupling causes an important class of bugs to be ignored and 
prevents an important class of circuits from being verified. 

For, example, consider the two three-transistor RAMS in Figure 12.1. The cell 
on the left will work, but the one on the right will not work. It fails due to capacitive 
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Figure 12.2: Bootstrap Driver. This device has much faster response and drive than 
expected because of capacitive coupling driving critical nodes high. 


coupling: it is impossible to store a high value on the storage node. Silica Pithecus 
does not detect this bug. 

As an example of a circuit we would like to be able to verify, consider a bootstrap 
driver (Figure 12.2), which is used in time-critical applications. Assume that the 
bootstrap node, driven node, and input node are initially at ground. The driven 
nodes capacitance is much greater than the bootstrap node’s capacitance. The 
bootstrap driver operates as follows: 

1. When the input node rises to Vdd the bootstrap node rises with it. The 
driven node does not begin to rise until after the bootstrap node exceeds the 
threshold for Ql. The driven node does not rise as quickly as the bootstrap 
node because of its greater capacitance. 

2. At some point after Ql turns on, the isolation transistor turns off, isolating the 
bootstrap node. The isolation transistor turns off when the bootstrap node 
rises to within a threshold voltage of the input node. The isolation transistor 
will remain off even if the bootstrap node continues to rise. At this time there 
is a voltage differential across the coup ling capacitor. 

3. After this point, as the driven node continues to rise the capacitor maintains 

the voltage differential produced above thereby driving the bootstrap node 
even higher. 

4. Because the isolation transistor remains off, the bootstrap node can be driven 
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fairly high. In some configurations it can reach eight volts. 1 11 

5. As the bootstrap node goes up the voltage on the gate of the pullup goes up 
well beyond five volts thereby allowing the driven node to reach Vdd. 

As a result of this process the driven node rises much faster and higher than 
if the input node were connected directly to the driven node. A system ignoring 
capacitive coupling calculates an incorrect final voltage (two threshold drops below 

Vdd) for the driven node, as well as an incorrect estimate of the time it takes to 
stabilize. 

The bootstrap driver is not a digital circuit according the definition given in 
Chapter 1. According to that definition, a circuit is not digital when the rate of 
change of voltage affects the final state of a circuit. The correct operation of the 
bootstrap driver requires the bootstrap node to rise much faster than the driven 
node. If the driven node rises faster, then there is no “bootstrap” action. 

I don’t know how to extend the theory to include bootstrap drivers and similar 
circuits. This research should be done. 


12.5 Multiple Abstraction Functions 

We concentrated on avoiding stored charge and ensuring voltage levels were ade¬ 
quate. An abstraction was formulated which ensured these two properties. It might 
be the case that more analog-like circuits, such as bootstrap devices and sense am¬ 
plifiers, could be verified by positing the proper abstraction functions. Ideally, 

representations of circuit behavior could be developed which make invalid signals 
apparent. 

When a system contains multiple abstraction functions the user would have to 
declare which abstraction functions go with which nodes. There might be heuristics 

which allow a system to guess correctly 95% of the time and to otherwise ask the 
user. 


1 “Hot Clock nMOS” which uses 7 volt clocks and 5 volt Vdd has 

11 volts [Seits]. 


achieved bootstrap voltages of 
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schematic of an MOS circuit and a specification of the circuit's intended digital 
behavior. Silica Pithecus determines if the circuit meets its specification. 

If the circuit fails to meet its specification Silica Pithecus returns to the 
designer the reason for the failure. Unlike earlier verifiers which modelled 
primitives (e.g., transistors) as unidirectional digital devices, Silica Pithecus 
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Abstract (cont) 


models primitives more realistically. Transistors are modelled as bidirectional 
devices of varying resistances, and nodes are modelled as capacitors. Silica Pithecus 
operates hierarchically, interactively, and incrementally. 

Major contributions of this research include a formal understanding of the 
relationship between different behavioral descriptions (e.g., signal, boolean, 
and arithmetic descriptions) of the same device, and a formalization of the 
relationship between the structure, behavior, and context of a device. Given these 
formal structures, my methods find sufficient conditions on the inputs of circuits 
which guarantee the correct operation of the circuit in the desired descriptive 
domain. These methods are algorithmic and complete. They also handle complex 
phenomena such as races and charge sharing. Informal notions such as races 
and hazards are shown to be derivable from the correctness conditions used by my 
methods. 
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